Dell Unity: Filer eller mapper i NFS-eksport kan ikke tilgås efter Unity-opgradering til 5.5

• Brugere bemærker muligvis, at nogle filer ikke kan tilgås, eller at mapper ikke kan vises efter Unity-opgradering til 5.5, 
• Problemet opstår kun under følgende omstændigheder: 
  • Klienten monterer NFS-eksporten ved hjælp af NFSv4.2, adgangen er god, hvis klienten monterer NFS-eksporten ved hjælp af NFSv3 eller NFSv4.0 eller 4.1.  
  • SELinux er aktiveret på Linux-klienten. 

Her er et eksempel:

• Bruger test_user kan ikke angive indholdet af NFS-monteringspunktet /mnt ved montering ved hjælp af 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

• Bruger test_user kan vise den samme mappe, efter at klienten har genmonteret NFS-eksporten ved hjælp af 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

• Fra og med UnityOS 5.5 har Unity tilføjet understøttelse af NFSv4.2. NFSv4.2-protokolunderstøttelse giver ekstra sikkerhed og ydeevne, og NFS-attributunderstøttelse af reservefiler og NFS-mærkning.
• Funktionen Sikkerhedsmærkat i NFSV4.2 gør det muligt at gemme og håndhæve sikkerhedsmærkater (f.eks. SELinux-kontekster) via NFS-delinger. Denne funktion er som standard aktiveret på Unity NAS-serveren. 
• Når SELinux er aktiveret på en Linux-klient, tildeler den en sikkerhedsetiket til hvert objekt i systemerne, herunder filer, mapper, processer, porte og enheder. 
• Standardsikkerhedskonteksten, som SELinux tildeler filer i NFS-eksport, der er tilsluttet ved hjælp af NFS v3, V4.0 eller v4.1, er 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

• Når klienten aktiverer NFS-eksporten ved hjælp af NFS v4.2, ændres standardsikkerhedskonteksten for NFS-filer til 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

• Ændringen af sikkerhedskonteksten, især sikkerhedstypen fra nfs_t til default_t, kan forårsage nogle adgangsproblemer, da SELinux bestemmer adgangstilladelsen baseret på politikreglerne, der beregner sikkerhedstypen for brugeren eller processen og filer eller mapper.

Der er flere løsninger. Brugeren skal vælge én løsning baseret på sine prioriteter: sikkerhed, enkelhed eller funktionskrav. 

• Genmonter NFS-eksporten ved hjælp af NFSv4.1, NFSv4.0 eller NFSv3 fra klienten

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

• Monter NFS-eksporten ved hjælp af NFSv4.2, men angiv sikkerhedskomponenten

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

• Nedgrader NFSv4-versionen med maks. support på Unity fra v4.2 til v4.1. 

Dell Unity: Efter opgradering til Unity OE version 5.5 kan NFSv4-klienter ikke få adgang til data

• Deaktiver sikkerhedsmærkaten på Unity

Dell Unity: Sådan deaktiverer du Security Label over NFS på Unity OE 5.5 (kan rettes af brugeren)

• Skift sikkerhedstypen for filerne i NFS-eksport til de relevante baseret på kravet. 

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

Følgende procedure kan følges for at foretage fejlfinding af SELinux-adgangsproblemet. 

1. Bestem brugerens sikkerhedskontekst.

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

2. Bekræft, at NFS-eksporten er aktiveret ved hjælp af NFSv4.2 og seclabel er aktiveret. 

[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. Kontrollér filsikkerhedskonteksten, og genskab problemet

[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. Tjek auditlog for at bekræfte, hvorfor kommandoen mislykkes.

[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. Når brugeren kører ls på /mnt, arver ls-processen brugerens sikkerhedstype, bestemmer SELinux-systemet, om sikkerhedstypen user_t har læsetilladelse til filtypen default_t. I dette tilfælde ls Kommandoen mislykkedes, fordi kildesikkerhedstypen user_t ikke har læsetilladelse til filens sikkerhedstype default_t. 

Dette kan bekræftes ved at kontrollere sikkerhedspolitikkens regler.

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

6. Følgende kommando viser alle de tilladelser, user_t har til 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. I ovenstående output tilhører user_t domæne, og default_t tilhører base_file_type. Så user_t har kun getattr, åbn, søg efter tilladelse til mappen med 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. Brugeren kan cd til /mnt da åben er tilladt. 

>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