Dell Unity: Bestanden of mappen in NFS-export zijn niet toegankelijk na Unity-upgrade naar 5.5

• Gebruikers merken mogelijk dat sommige bestanden niet kunnen worden geopend of mappen niet kunnen worden weergegeven nadat Unity is bijgewerkt naar 5.5, 
• Het probleem doet zich alleen voor onder de volgende omstandigheden: 
  • De client koppelt de NFS-export met NFSv4.2. De toegang is goed als de client de NFS-export koppelt met NFSv3, NFSv4.0 of 4.1.  
  • SELinux is ingeschakeld op de Linux-client. 

Hier is een voorbeeld:

• Gebruiker test_user kan de inhoud van NFS-koppelpunt niet weergeven /mnt bij montage met behulp van 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

• Gebruikers test_user kunnen dezelfde map weergeven nadat de client de NFS-export opnieuw heeft gekoppeld met NFSv4.1.

[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

• Vanaf UnityOS 5.5 heeft Unity support toegevoegd voor NFSv4.2. Ondersteuning voor NFSv4.2-protocol zorgt voor extra beveiliging en prestaties, en ondersteuning voor NFS-kenmerken van reservebestanden en NFS-labeling.
• Met de functie Beveiligingslabel in NFSV4.2 kunnen beveiligingslabels (zoals SELinux-contexten) worden opgeslagen en afgedwongen via NFS-shares. Deze functie is standaard ingeschakeld op de Unity NAS-server. 
• Wanneer SELinux is ingeschakeld op een Linux-client, wijst het een beveiligingslabel toe aan elk object in de systemen, inclusief bestanden, mappen, processen, poorten en apparaten. 
• De standaard beveiligingscontext die SELinux toewijst aan bestanden in NFS-export die zijn gekoppeld met NFS v3, V4.0 of v4.1 is 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

• Wanneer de client de NFS-export koppelt met behulp van NFS v4.2, wordt de standaard beveiligingscontext van NFS-bestanden gewijzigd in 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

• De verandering van de beveiligingscontext, met name het beveiligingstype, van nfs_t naar default_t kan enkele toegangsproblemen veroorzaken, aangezien SELinux de toegangsrechten bepaalt op basis van de beleidsregels die het beveiligingstype van de gebruiker of het proces en bestanden of mappen berekenen.

Er zijn verschillende oplossingen. De gebruiker moet één oplossing kiezen op basis van zijn prioriteiten: beveiliging, eenvoud of functievereisten. 

• Koppel de NFS-export opnieuw met NFSv4.1, NFSv4.0 of NFSv3 vanaf de client

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

• Koppel de NFS-export met behulp van NFSv4.2, maar specificeer de beveiligingsconext

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

• Downgrade de max. support NFSv4-versie op Unity van v4.2 naar v4.1. 

Dell Unity: Na een upgrade naar Unity OE versie 5.5 hebben NFSv4-clients geen toegang tot data

• Schakel het beveiligingslabel op Unity uit

Dell Unity: Beveiligingslabel uitschakelen via NFS op Unity OE 5.5 (op te lossen door gebruiker)

• Wijzig het beveiligingstype van de bestanden in NFS-export naar de juiste bestanden op basis van de vereiste. 

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

De volgende procedure kan worden gevolgd om het probleem met de toegang tot SELinux op te lossen. 

1. Bepaal de beveiligingscontext van de gebruiker.

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

2. Controleer of de NFS-export wordt gekoppeld met behulp van NFSv4.2 en seclabel is ingeschakeld. 

[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. Controleer de beveiligingscontext van het bestand en reproduceer het probleem

[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. Controleer op auditlog om te bevestigen waarom de opdracht mislukt.

[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. Wanneer de gebruiker ls op de /mnt, neemt het ls-proces het beveiligingstype van de gebruiker over, het SELinux-systeem bepaalt of het beveiligingstype user_t leesrechten heeft op het bestandstype default_t. In dit geval is de ls Opdracht mislukt omdat de user_t van het bronbeveiligingstype geen leesmachtiging heeft op het beveiligingstype van het bestand default_t. 

Dit kan worden bevestigd door de regels van het beveiligingsbeleid te controleren.

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

6. De volgende opdracht bevat alle machtigingen van het type user_t heeft voor type default_t.

[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 de bovenstaande uitvoer hoort user_t bij het domein en default_t bij base_file_type. Dus user_t heeft alleen getattr, open, zoekmachtiging op de directory met default_t type.

[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. De gebruiker kan cd Aan /mnt aangezien open is toegestaan. 

>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