Dell Unity: No se puede acceder a los archivos o carpetas en la exportación NFS después de la actualización de Unity a 5.5

• Es posible que los usuarios noten que no se puede acceder a algunos archivos o que no se pueden enumerar las carpetas después de la actualización de Unity a 5.5. 
• El problema solo se produce en las siguientes condiciones: 
  • El cliente monta la exportación NFS mediante NFSv4.2; el acceso es válido si el cliente monta la exportación NFS mediante NFSv3, NFSv4.0 o 4.1.  
  • SELinux está activado en el cliente Linux. 

He aquí un ejemplo:

• El test_user de usuario no puede enumerar el contenido del punto de montaje de NFS /mnt cuando se monta mediante 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

• El usuario test_user puede enumerar la misma carpeta después de que el cliente vuelva a montar la exportación NFS mediante 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

• A partir de UnityOS 5.5, Unity agregó compatibilidad con NFSv4.2. La compatibilidad con el protocolo NFSv4.2 aporta seguridad y rendimiento adicionales, y compatibilidad con los atributos de NFS de archivos de repuesto y etiquetado de NFS.
• La función de etiqueta de seguridad en NFSV4.2 permite que las etiquetas de seguridad (como los contextos de SELinux) se almacenen y se apliquen en los recursos compartidos NFS. De manera predeterminada, esta característica está habilitada en el servidor NAS de Unity. 
• Cuando SELinux está activado en un cliente Linux, asigna una etiqueta de seguridad a todos los objetos de los sistemas, incluidos archivos, carpetas, procesos, puertos y dispositivos. 
• El contexto de seguridad predeterminado que SELinux asigna a los archivos en la exportación NFS montados mediante NFS v3, v4.0 o v4.1 es 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

• Cuando el cliente monta la exportación de NFS mediante NFS v4.2, el contexto de seguridad predeterminado de los archivos NFS cambia a 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

• El cambio del contexto de seguridad, especialmente del tipo de seguridad de nfs_t a default_t, puede causar algunos problemas de acceso, ya que SELinux determina el permiso de acceso en función de las reglas de política que calculan el tipo de seguridad del usuario o proceso y los archivos o carpetas.

Hay varias soluciones alternativas. El usuario debe elegir una solución en función de sus prioridades: seguridad, simplicidad o requisitos de características. 

• Volver a montar la exportación de NFS mediante NFSv4.1, NFSv4.0 o NFSv3 desde el cliente

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

• Monte la exportación de NFS mediante NFSv4.2, pero especifique el cosiguiente de seguridad

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

• Degradar la versión NFSv4 de soporte máximo en Unity de v4.2 a v4.1. 

Dell Unity: Después de la actualización a Unity OE versión 5.5, los clientes NFSv4 no pueden acceder a los datos

• Deshabilitar la etiqueta de seguridad en Unity

Dell Unity: Cómo deshabilitar la etiqueta de seguridad mediante NFS en Unity OE 5.5 (corregible por el usuario)

• Cambie el tipo de seguridad de los archivos en la exportación NFS a los correspondientes según los requisitos. 

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

Se puede seguir el siguiente procedimiento para solucionar el problema de acceso a SELinux. 

1. Determine el contexto de seguridad del usuario.

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

2. Confirme que la exportación NFS esté montada mediante NFSv4.2 y seclabel está habilitado. 

[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. Compruebe el contexto de seguridad del archivo y reproduzca el 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

4. Comprobar auditlog para confirmar por qué falla el comando.

[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. Cuando el usuario ejecuta ls En el /mnt, el proceso ls hereda el tipo de seguridad del usuario, el sistema SELinux determina si el tipo de seguridad user_t tiene permiso de lectura en el tipo de archivo default_t. En este caso, el método ls El comando falló porque el tipo de seguridad de origen user_t no tiene permiso de lectura en el tipo de seguridad del archivo default_t. 

Esto se puede confirmar mediante la comprobación de las reglas de la política de seguridad.

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

6. El siguiente comando enumera todos los tipos de permisos user_t tiene en el 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;

7. En la salida anterior, user_t pertenece al dominio y default_t pertenece al base_file_type. Así que user_t solo tiene getattr, abra y busque el permiso en el directorio con el 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>

8. El usuario puede: cd como /mnt ya que se permite abrir. 

>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