Dell Unity: kan ikke få adgang til filer eller mapper i NFS-eksport efter opgradering til Unity OE 5.5

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

Her er et eksempel:

• Bruger test_user kan ikke angive indholdet af NFS-monteringspunkt /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 angive den samme mappe efter klientgenmontering af 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

• Unity har tilføjet understøttelse til NFSv4.2 startende med Unity OE 5.5. NFSv4.2 protokolunderstøttelse giver ekstra sikkerhed og ydeevne, og NFS-attributunderstøttelse af reservefiler og NFS-mærkning.
• Sikkerhedsmærkatfunktionen i NFSV4.2 Tillader sikkerhedsmærkater (f.eks. SELinux kontekster), der skal lagres og håndhæves over NFS-aktier. Denne funktion er som standard aktiveret på Unity NAS-serveren. 
• Hvornår SELinux er aktiveret på en Linux-klient, tildeler den en sikkerhedsetiket til hvert objekt i systemerne, herunder filer, mapper, processer, porte og enheder. 
• Den standardsikkerhedskontekst, der SELinux tildeler til filer i NFS-eksport, der er monteret ved hjælp af NFS v3, V4.0Eller 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 monterer 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 som SELinux Bestemmer adgangstilladelsen baseret på de politikregler, der beregner sikkerhedstypen for brugeren eller processen og filer eller mapper.

Brugerne bør vælge én løsning baseret på deres prioriteter: sikkerhed, enkelhed eller funktionskrav. 
 

• Genmonter NFS-eksporten ved hjælp af NFSv4.1, NFSv4.0, or NFSv3 Fra klient:

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

• Montér NFS-eksporten ved hjælp af NFSv4.2 Men angiv sikkerhedskonteksten:

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

• Nedgrader den maksimale understøttelse NFSv4 version 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 adgangsproblem. 

1. Bestem brugerens sikkerhedskontekst:

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

2. Bekræft, at NFS-eksporten er monteret 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 Sådan bekræfter du, 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, ls processen arver brugerens sikkerhedstype, SELinux Systemet bestemmer, om sikkerhedstypen user_t har læsetilladelse til filtypen default_t. I dette tilfælde ls Kommandoen mislykkedes, fordi kildesikkerhedstypen user_t Har ikke 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 tilladelsestyper user_t har på 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, user_t tilhører domænet, og default_t tilhører base_file_type.
   Så user_t har kun getattr, åbn, søg tilladelse på 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