Dell Unity: Non è possibile accedere a file o cartelle nell'esportazione NFS dopo l'aggiornamento di Unity alla versione 5.5

Riepilogo: L'utente Linux potrebbe non essere in grado di accedere ad alcuni file o cartelle nell'esportazione NFS (Network File System) dopo l'aggiornamento di Unity alla versione 5.5. (correggibile dall'utente) (in inglese) ...

Questo articolo si applica a Questo articolo non si applica a Questo articolo non è legato a un prodotto specifico. Non tutte le versioni del prodotto sono identificate in questo articolo.

Sintomi

  • Gli utenti potrebbero notare che non è possibile accedere ad alcuni file o che non è possibile elencare le cartelle dopo l'aggiornamento di Unity alla versione 5.5. 
  • Il problema si verifica solo nelle seguenti condizioni: 
    • Il client esegue il mount dell'esportazione NFS utilizzando NFSv4.2; l'accesso è valido se il client esegue il mount dell'esportazione NFS utilizzando NFSv3, NFSv4.0 o 4.1.  
    • SELinux è abilitato sul client Linux. 

Ecco un esempio:

  • L'utente test_user non può elencare il contenuto del mount point NFS /mnt durante il mounting utilizzando 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'utente test_user può elencare la stessa cartella dopo che il client ha rimontato l'esportazione NFS utilizzando 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

Causa

  • A partire da UnityOS 5.5, Unity ha aggiunto il supporto per NFSv4.2. Il supporto del protocollo NFSv4.2 offre maggiore sicurezza e prestazioni, mentre il supporto degli attributi NFS dei file di riserva e dell'etichettatura NFS.
  • La funzionalità delle etichette di sicurezza in NFSV4.2 consente di archiviare e applicare le etichette di sicurezza (ad esempio i contesti SELinux) sulle condivisioni NFS. Per impostazione predefinita, questa funzione è abilitata sul server NAS Unity. 
  • Quando SELinux è abilitato su un client Linux, assegna un'etichetta di sicurezza a ogni oggetto nei sistemi, inclusi file, cartelle, processi, porte e dispositivi. 
  • Il contesto di sicurezza predefinito assegnato da SELinux ai file nell'esportazione NFS montati utilizzando NFS v3, v4.0 o v4.1 è 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
  • Quando il client esegue il mount dell'esportazione NFS utilizzando NFS v4.2, il contesto di sicurezza predefinito dei file NFS cambia 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
  • La modifica del contesto di sicurezza, in particolare il tipo di sicurezza, da nfs_t a default_t può causare alcuni problemi di accesso in quanto SELinux determina l'autorizzazione di accesso in base alle regole della policy che calcolano il tipo di sicurezza dell'utente o del processo e dei file o delle cartelle.

Risoluzione

Esistono diverse soluzioni alternative. L'utente deve scegliere una soluzione in base alle sue priorità: sicurezza, semplicità o requisiti di funzionalità. 

  • Eseguire nuovamente il mount dell'esportazione NFS utilizzando NFSv4.1, NFSv4.0 o NFSv3 dal client
mount -o vers=4.1 <nas server IP>:/<export> /<localmountpoint>
  • Eseguire il mounting dell'esportazione NFS utilizzando NFSv4.2, ma specificare il metodo di sicurezza
mount -o context=system_u:object_r:nfs_t:s0 <nas server IP>:/<export> /<localmountpoint>
  • Eseguire il downgrade della versione NFSv4 con supporto massimo su Unity da v4.2 a v4.1. 

Dell Unity: Dopo l'aggiornamento a Unity OE versione 5.5, i client NFSv4 non possono accedere ai dati

  • Disabilitare l'etichetta di sicurezza su Unity

Dell Unity: Come disabilitare l'etichetta di sicurezza su NFS su Unity OE 5.5 (correggibile dall'utente)

  • Modificare il tipo di sicurezza dei file nell'esportazione NFS scegliendo quelli appropriati in base ai requisiti. 
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

Informazioni aggiuntive

È possibile seguire la seguente procedura per risolvere il problema di accesso a SELinux. 

1. Determinare il contesto di sicurezza dell'utente.

[test_user@RHEL4 ~]$ id -Z
user_u:user_r:user_t:s0
  1. Verificare che l'esportazione NFS sia montata utilizzando NFSv4.2 e seclabel è abilitato. 
[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)
  1. Controllare il contesto di sicurezza dei file e riprodurre il problema
[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
  1. Verificare all'indirizzo auditlog per confermare il motivo per cui il comando non riesce.
[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
  1. Quando l'utente esegue ls sulla pagina /mnt, il processo ls eredita il tipo di sicurezza dell'utente, il sistema SELinux determina se il tipo di sicurezza user_t dispone dell'autorizzazione di lettura sul tipo di file default_t. In questo caso, il ls Il comando non è riuscito perché il tipo di protezione di origine user_t non dispone dell'autorizzazione di lettura per il tipo di sicurezza del file default_t. 

Questa condizione può essere confermata controllando le regole dei criteri di protezione.

root@RHEL4 ~]# sesearch -A -s user_t -t default_t -p read
[root@RHEL4 ~]#
  1. Il comando seguente elenca tutte le autorizzazioni di cui user_t dispone per il tipo 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;
  1. Nell'output precedente, user_t appartiene al dominio e default_t appartiene a base_file_type. Quindi user_t solo getattr, aprire, l'autorizzazione di ricerca nella directory con tipo 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>
  1. L'utente può cd su /mnt poiché l'apertura è consentita. 
>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

Prodotti interessati

Dell EMC Unity, Dell Unity Operating Environment (OE)
Proprietà dell'articolo
Numero articolo: 000334013
Tipo di articolo: Solution
Ultima modifica: 25 giu 2025
Versione:  2
Trova risposta alle tue domande dagli altri utenti Dell
Support Services
Verifica che il dispositivo sia coperto dai Servizi di supporto.