Dell Unity : impossible d’accéder aux fichiers ou dossiers dans l’exportation NFS après la mise à niveau vers Unity OE 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 l’environnement d’exploitation (OE) 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, ou NFSv4.0, ou NFSv 4.1.  
  • SELinux est activé sur le client Linux. 

Voici un exemple :

• Utilisateur test_user impossible de 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

• 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

• Unity a ajouté la prise en charge de NFSv4.2 à partir de Unity OE 5.5. NFSv4.2 La prise en charge des protocoles offre une sécurité et des performances supplémentaires, et la prise en charge des attributs NFS des fichiers de secours et de l’étiquetage NFS.
• La fonction d’étiquette de sécurité dans NFSV4.2 autorise les étiquettes de sécurité (telles que SELinux contexts) à stocker et à appliquer 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 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 to default_t peut entraîner des problèmes d’accès tels que SELinux Détermine l’autorisation d’accès en fonction des règles de règle qui calculent le type de sécurité de l’utilisateur ou du processus et des fichiers ou dossiers.

• Ce problème est résolu dans Unity OE 5.5.3. 
  • Notes de mise à jour pour la version actuelle de la famille Dell Unity™ : 5.5.3.0.5.046 

Si une mise à niveau n’est pas envisageable, il existe des solutions de contournement pour éviter ce problème.
Les utilisateurs doivent choisir une solution en fonction de leurs priorités : sécurité, simplicité ou exigences en matière de fonctionnalités. 
 

• Remontez l’exportation NFS à l’aide de NFSv4.1, NFSv4.0, or NFSv3 De la part du client :

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

• Montez l’exportation NFS à l’aide de NFSv4.2 mais précisez le contexte de sécurité :

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

• Rétrograder la prise en charge maximale NFSv4 version sur Unity à partir de v4.2 to 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ésactivez 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

La procédure suivante peut être suivie pour dépanner le SELinux Problème d’accès. 

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 la commande suivante : 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é des fichiers 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' /mntLla ls hérite du type de sécurité de l’utilisateur, l’attribut SELinux Le système 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 type de sécurité source user_t N’a pas d’autorisation de lecture sur le type de sécurité du fichier default_t. 

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 tous les types d’autorisations user_t a 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.
   Ainsi user_t n’a qu’une getattr, open, l’autorisation de recherche sur le répertoire avec 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. 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