Dell Unity: Auf Dateien oder Ordner im NFS-Export kann nach dem Unity-Upgrade auf 5.5 nicht zugegriffen werden

• NutzerInnen stellen möglicherweise fest, dass nach dem Unity-Upgrade auf 5.5 nicht auf einige Dateien zugreifen oder Ordner nicht aufgelistet werden können. 
• Das Problem tritt nur unter den folgenden Bedingungen auf: 
  • Der Client mountet den NFS-Export mit NFSv4.2. Der Zugriff ist gut, wenn der Client den NFS-Export mit NFSv3 oder NFSv4.0 oder 4.1 mountet.  
  • SELinux ist auf dem Linux-Client aktiviert. 

Hier ist ein Beispiel:

• Nutzer test_user kann den Inhalt des NFS-Einhängepunkts nicht auflisten /mnt beim Mounten mit NFSv4.2. 

[test_user@RHEL4 ~]$ mount -v | grep -i mnt
10.xx.xx.48:/test on /mnt type nfs4 (rw,relatime,seclabel,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.227.xxx.129,local_lock=none,addr=10.60.15.48)

[test_user@RHEL4 ~]$ ls -al /mnt
ls: cannot open directory '/mnt': Permission denied

• Nutzer test_user können denselben Ordner nach dem erneuten Mounten des NFS-Exports durch den Client mit NFSv4.1 auflisten.

[test_user@RHEL4 ~]$ mount -v | grep -i mnt
10.xx.xx.48:/test on /mnt type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.227.xxx.129,local_lock=none,addr=10.60.15.48)


[test_user@RHEL4 ~]$ ls -al /mnt
total 16
drwxrwxrwx.  6 root root 8192 Jun 18 03:21 .
dr-xr-xr-x. 20 root root  271 Jun  8 19:07 ..
dr-xr-xr-x.  2 root bin   152 Apr 14 03:56 .etc
drwxr-xr-x.  2 root root  152 Jun 18 03:20 folder
drwxr-xr-x.  2 root root 8192 Apr 14 03:56 lost+found

• Ab UnityOS 5.5 unterstützt Unity NFSv4.2. Die NFSv4.2-Protokollunterstützung sorgt für zusätzliche Sicherheit und Leistung, und die NFS-Attributunterstützung für Ersatzdateien und NFS-Etikettierung sorgt für zusätzliche Sicherheit.
• Mit der Sicherheitskennzeichnungsfunktion in NFSV4.2 können Sicherheitsbezeichnungen (z. B. SELinux-Kontexte) über NFS-Shares gespeichert und durchgesetzt werden. Standardmäßig ist diese Funktion auf dem Unity-NAS-Server aktiviert. 
• Wenn SELinux auf einem Linux-Client aktiviert ist, wird jedem Objekt in den Systemen, einschließlich Dateien, Ordnern, Prozessen, Ports und Geräten, eine Sicherheitskennzeichnung zugewiesen. 
• Der Standardsicherheitskontext, den SELinux Dateien im NFS-Export zuweist, die mit NFS v3, v4.0 oder v4.1 gemountet wurden, ist system_u:object_r:nfs_t:s0.

[root@rhel8 test]# ls -alZ testv4.1
-rw-r--r--. 1 root root system_u:object_r:nfs_t:s0 0 Jun  1 21:47 testv4.1

• Wenn der Client den NFS-Export mit NFS v4.2 mountet, ändert sich der Standardsicherheitskontext von NFS-Dateien zu unconfined_u:object_r:default_t:s0.

[root@rhel8 test]# ls -alZ testv4.2
-rw-r--r--. 1 root root unconfined_u:object_r:default_t:s0 0 Jun  1  2025 testv4.2

• Die Änderung des Sicherheitskontexts, insbesondere des Sicherheitstyps von nfs_t zu default_t, kann zu Zugriffsproblemen führen, da SELinux die Zugriffsberechtigung basierend auf den Richtlinienregeln bestimmt, die den Sicherheitstyp des Benutzers oder Prozesses und der Dateien oder Ordner berechnen.

Es gibt mehrere Workarounds. Der Nutzer sollte eine Lösung basierend auf seinen Prioritäten auswählen: Sicherheit, Einfachheit oder Funktionsanforderungen. 

• Mounten Sie den NFS-Export mithilfe von NFSv4.1, NFSv4.0 oder NFSv3 vom Client erneut

mount -o vers=4.1 <nas server IP>:/<export> /<localmountpoint>

• Mounten Sie den NFS-Export mit NFSv4.2, geben Sie jedoch den Sicherheitsconext an

mount -o context=system_u:object_r:nfs_t:s0 <nas server IP>:/<export> /<localmountpoint>

• Downgrade der maximal unterstützten NFSv4-Version auf Unity von v4.2 auf v4.1. 

Dell Unity: Nach dem Upgrade auf Unity OE-Version 5.5 können NFSv4-Clients nicht auf Daten zugreifen.

• Deaktivieren der Sicherheitskennzeichnung auf Unity

Dell Unity: Deaktivieren der Sicherheitskennzeichnung über NFS auf Unity OE 5.5 (vom Nutzer korrigierbar)

• Ändern Sie den Sicherheitstyp der Dateien im NFS-Export je nach Anforderung in die entsprechenden. 

chcon <user>:<role>:<type>:<level> <file/folders>

For example, change the file type to nfs_t. 

[root@RHEL4 /]# ls -alZ /mnt/nfsv4.2
-rw-r--r--. 1 root root system_u:object_r:default_t:s0 0 Jun 17 00:53 /mnt/nfsv4.2
[root@RHEL4 /]# chcon -t nfs_t /mnt/nfsv4.2
[root@RHEL4 /]# ls -alZ /mnt/nfsv4.2
-rw-r--r--. 1 root root system_u:object_r:nfs_t:s0 0 Jun 17 00:53 /mnt/nfsv4.2

Das folgende Verfahren kann befolgt werden, um das SELinux-Zugriffsproblem zu beheben. 

1. Bestimmen Sie den Sicherheitskontext des Nutzers.

[test_user@RHEL4 ~]$ id -Z
user_u:user_r:user_t:s0

2. Vergewissern Sie sich, dass der NFS-Export mit NFSv4.2 gemountet ist und seclabel aktiviert ist. 

[test_user@RHEL4 ~]$ mount -v | grep mnt
10.xx.xx.48:/test on /mnt type nfs4 (rw,relatime,seclabel,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.227.xxx.129,local_lock=none,addr=10.xx.xx.48)

3. Überprüfen Sie den Dateisicherheitskontext und reproduzieren Sie das Problem

[test_user@RHEL4 ~]$ ls -aldZ /mnt
drwxrwxrwx. 6 root root system_u:object_r:default_t:s0 8192 Jun 17 07:44 /mnt

[test_user@RHEL4 ~]$ ls -al /mnt
ls: cannot open directory '/mnt': Permission denied

4. Suchen Sie unter auditlog , um zu bestätigen, warum der Befehl fehlschlägt.

[root@RHEL4 ~]# ausearch -m avc -ts recent | tail
----
time->Tue Jun 17 18:30:59 2025
type=PROCTITLE msg=audit(1750xxxx59.577:8407): proctitle=6C73002D2D636F6C6F723Dxxxxx46F002D616C002F6D6E74
type=SYSCALL msg=audit(1750203059.577:8407): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5563f160ca70 a2=90800 a3=0 items=0 ppid=104637 pid=104661 auid=10086 uid=10086 gid=10086 euid=10086 suid=10086 fsuid=10086 egid=10086 sgid=10086 fsgid=10086 tty=pts1 ses=246 comm="ls" exe="/usr/bin/ls" subj=user_u:user_r:user_t:s0 key=(null)
type=AVC msg=audit(1750xxxx59.577:8407): avc:  denied  { read } for  pid=104661 comm="ls" name="/" dev="0:47" ino=2 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir permissive=0

5. Wenn der Nutzer ls am /mnt, erbt der ls-Prozess den Sicherheitstyp des Benutzers, bestimmt das SELinux-System, ob der Sicherheitstyp user_t Leseberechtigung für den Dateityp default_t hat. In diesem Fall wird die ls Der Befehl ist fehlgeschlagen, da der Quellsicherheitstyp user_t keine Leseberechtigung für den Sicherheitstyp default_t der Datei hat. 

Dies kann durch Überprüfen der Regeln der Sicherheitsrichtlinie bestätigt werden.

root@RHEL4 ~]# sesearch -A -s user_t -t default_t -p read
[root@RHEL4 ~]#

6. Mit dem folgenden Befehl werden alle Berechtigungen des Typs user_t für Typ default_t aufgelistet.

[root@RHEL4 ~]# sesearch -A -s user_t -t default_t
allow domain base_file_type:dir { getattr open search };  
allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
allow user_usertype file_type:filesystem getattr;

7. In der obigen Ausgabe gehört user_t zur Domäne und default_t zu base_file_type. user_t hat also nur getattr, öffnen, Suchberechtigung für das Verzeichnis mit default_t Typ.

[root@RHEL4 mnt]# seinfo -t default_t -x

Types: 1
   type default_t, base_file_type, file_type, mountpoint, non_auth_file_type, non_security_file_type;


[root@RHEL4 mnt]# seinfo -t user_t -x | grep domain
   type user_t, application_domain_type, nsswitch_domain, corenet_unlabeled_type, domain, kernel_system_state_reader, netlabel_peer_type, privfd, process_user_target, scsi_generic_read, scsi_generic_write, syslog_client_type, pcmcia_typeattr_1, user_usertype, login_userdomain, userdomain, unpriv_userdomain, userdom_home_reader_type, userdom_filetrans_type, xdmhomewriter, x_userdomain, x_domain, dridomain, xdrawable_type, xcolormap_type;
/pre>

8. Der Nutzer kann cd an /mnt da offen zulässig ist. 

>allow domain base_file_type:dir { getattr open search };   <<<<

[test_user@RHEL4 ~]$ cd /mnt
[test_user@RHEL4 mnt]$ ls
ls: cannot open directory '.': Permission denied