Dell Unity : Les fichiers ou dossiers dans l’exportation NFS ne sont pas accessibles après la mise à niveau de Unity vers la version 5.5

• Les utilisateurs peuvent remarquer que certains fichiers ne sont pas accessibles ou que certains dossiers ne peuvent pas être répertoriés après la mise à niveau de Unity vers la version 5.5. 
• Le problème se produit uniquement dans les conditions suivantes : 
  • Le client monte l’exportation NFS à l’aide de NFSv4.2, l’accès est bon si le client monte l’exportation NFS à l’aide de NFSv3, NFSv4.0 ou 4.1.  
  • SELinux est activé sur le client Linux. 

Voici un exemple :

• L’utilisateur test_user ne peut pas répertorier le contenu du point de montage NFS /mnt lors du montage à l’aide de 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

• L’utilisateur test_user peut répertorier le même dossier après le remontage de l’exportation NFS par le client à l’aide de 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

• À partir de UnityOS 5.5, Unity a ajouté la prise en charge de NFSv4.2. La prise en charge du protocole NFSv4.2 apporte une sécurité et des performances supplémentaires, ainsi que la prise en charge des attributs NFS des fichiers de secours et de l’étiquetage NFS.
• La fonctionnalité d’étiquette de sécurité dans NFSV4.2 permet de stocker et d’appliquer des étiquettes de sécurité (telles que des contextes SELinux) sur des partages NFS. Par défaut, cette fonctionnalité est activée sur le serveur NAS Unity. 
• Lorsque SELinux est activé sur un client Linux, il attribue une étiquette de sécurité à chaque objet du système, y compris les fichiers, dossiers, processus, ports et périphériques. 
• Le contexte de sécurité par défaut que SELinux attribue aux fichiers dans l’exportation NFS montée à l’aide de NFS v3, v4.0 ou v4.1 est 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

• Lorsque le client monte l’exportation NFS à l’aide de NFS v4.2, le contexte de sécurité par défaut des fichiers NFS devient 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

• La modification du contexte de sécurité, en particulier le type de sécurité de nfs_t à default_t peut entraîner des problèmes d’accès, car SELinux détermine l’autorisation d’accès en fonction des règles de stratégie qui calculent le type de sécurité de l’utilisateur ou du processus et des fichiers ou dossiers.

Il existe plusieurs solutions de contournement. L’utilisateur doit choisir une solution en fonction de ses priorités : sécurité, simplicité ou exigences en matière de fonctionnalités. 

• Remontez l’exportation NFS à l’aide de NFSv4.1, NFSv4.0 ou NFSv3 à partir du client

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

• Montez l’exportation NFS à l’aide de NFSv4.2, mais spécifiez le conext de sécurité

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

• Rétrogradez la version NFSv4 maximale prise en charge sur Unity de v4.2 vers v4.1. 

Dell Unity : Après la mise à niveau vers Unity OE version 5.5, les clients NFSv4 ne peuvent pas accéder aux données

• Désactivation de l’étiquette de sécurité sur Unity

Dell Unity : Désactivation de l’étiquette de sécurité sur NFS sur Unity OE 5.5 (corrigible par l’utilisateur)

• Remplacez le type de sécurité des fichiers dans l’exportation NFS par les fichiers appropriés en fonction des besoins. 

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

Vous pouvez suivre la procédure suivante pour résoudre le problème d’accès SELinux. 

1. Déterminez le contexte de sécurité de l’utilisateur.

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

2. Vérifiez que l’exportation NFS est montée à l’aide de NFSv4.2 et seclabel est activé. 

[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. Vérifiez le contexte de sécurité du fichier et reproduisez le problème

[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. Check (Vérifier) auditlog pour confirmer la raison pour laquelle la commande échoue.

[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. Lorsque l’utilisateur exécute ls Sur l' /mnt, le processus ls hérite du type de sécurité de l’utilisateur, le système SELinux détermine si le type de sécurité user_t dispose d’une autorisation de lecture sur le type de fichier default_t. Dans ce cas, l’option ls La commande a échoué, car le user_t de type de sécurité source n’a pas d’autorisation de lecture sur le default_t de type de sécurité du fichier. 

Vous pouvez le confirmer en vérifiant les règles de la politique de sécurité.

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

6. La commande suivante répertorie toutes les autorisations dont user_t dispose sur le 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. Dans la sortie ci-dessus, user_t appartient au domaine et default_t appartient à base_file_type. Donc, user_t n’a getattr, ouvrir, l’autorisation de recherche sur le répertoire de type default_t.

[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. L’utilisateur peut : cd to /mnt puisque l’ouverture est autorisée. 

>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