Compartir vía

Descripción de las listas de control de acceso nfSv4.x en Azure NetApp Files

  • Artículo

El protocolo NFSv4.x puede proporcionar control de acceso en forma de listas de control de acceso (ACL), que conceptualmente es similar a las ACL usadas en SMB a través de permisos NTFS de Windows. Una ACL NFSv4.x consta de entradas de control de acceso (ACE) individuales, cada una de las cuales proporciona una directiva de control de acceso al servidor.

Diagrama de la entidad de control de acceso a Azure NetApp Files.

Cada ACL nfSv4.x se crea con el formato de type:flags:principal:permissions.

  • Tipo: el tipo de ACL que se va a definir. Entre las opciones válidas se incluyen Access (A), Deny (D), Audit (U), Alarm (L). Azure NetApp Files admite tipos de ACL de acceso, denegación y auditoría, pero auditar ACL, mientras se puede establecer, no genere registros de auditoría actualmente.
  • Marcas: agrega contexto adicional para una ACL. Hay tres tipos de marcas ACE: grupo, herencia y administración. Para obtener más información sobre las marcas, vea marcas ACE NFSv4.x.
  • Principal: define el usuario o grupo al que se asigna la ACL. Una entidad de seguridad de una ACL NFSv4.x usa el formato de name@ID-DOMAIN-STRING.COM. Para obtener información más detallada sobre las entidades de seguridad, vea usuarios y entidades de seguridad de grupo NFSv4.x.
  • Permisos: donde se define el nivel de acceso de la entidad de seguridad. Cada permiso se designa con una sola letra (por ejemplo, lectura obtiene "r", escritura obtiene "w" y etc.). El acceso total incorporaría cada carta de permiso disponible. Para obtener más información, vea permisos NFSv4.x.

A:g:group1@contoso.com:rwatTnNcCy es un ejemplo de una ACL válida, siguiendo el formato type:flags:principal:permissions. La ACL de ejemplo concede acceso completo al grupo group1 en el dominio de identificador de contoso.com.

Marcas DE ACE NFSv4.x

Una marca ACE ayuda a proporcionar más información sobre una ACE en una ACL. Por ejemplo, si se agrega una ACE de grupo a una ACL, se debe usar una marca de grupo para designar la entidad de seguridad es un grupo y no un usuario. Es posible que en entornos de Linux tenga un usuario y un nombre de grupo idénticos, por lo que la marca garantiza que se respeta una ACE, el servidor NFS debe saber qué tipo de entidad de seguridad se está definiendo.

Otras marcas se pueden usar para controlar los ACE, como la herencia y las marcas administrativas.

Marcas de acceso y denegación

Las marcas access (A) y deny (D) se usan para controlar los tipos ACE de seguridad. Una ACE de acceso controla el nivel de permisos de acceso en un archivo o carpeta para una entidad de seguridad. Una ACE de denegación prohíbe explícitamente que una entidad de seguridad acceda a un archivo o carpeta, incluso si se establece una ACE de acceso que permitiría que esa entidad de seguridad acceda al objeto. Denegar ACE siempre sobrepasan el acceso ACE. En general, evite el uso de ACE de denegación, ya que las ACL NFSv4.x siguen un “modelo de denegación” predeterminado, lo que significa que si no se agrega una ACL, la denegación es implícita. Denegar ACE puede crear complicaciones innecesarias en la administración de ACL.

Marcas de herencia

Las marcas de herencia controlan cómo se comportan las ACL en los archivos creados debajo de un directorio primario con el conjunto de marcas de herencia. Cuando se establece una marca de herencia, los archivos o directorios heredan las ACL de la carpeta primaria. Las marcas de herencia solo se pueden aplicar a directorios, por lo que cuando se crea un subdirectorio, hereda la marca. Los archivos creados debajo de un directorio primario con una marca de herencia heredan las ACL, pero no las marcas de herencia.

En la tabla siguiente se describen las marcas de herencia disponibles y sus comportamientos.

Marca de herencia Comportamiento
d - Los directorios debajo del directorio primario heredan la ACL
- La marca de herencia también se hereda
f - Los archivos debajo del directorio primario heredan la ACL
- Los archivos no establecen la marca de herencia
i Solo heredar; la ACL no se aplica al directorio actual, pero debe aplicar la herencia a objetos debajo del directorio.
n - Sin propagación de herencia
Después de heredar la ACL, las marcas heredadas se borran en los objetos siguientes al primario

Ejemplos de ACL de NFSv4.x

En el ejemplo siguiente, hay tres ACE diferentes con marcas de herencia distintas:

  • directory hereda solo (di)
  • el archivo solo hereda (fi)
  • tanto el archivo como el directorio heredan (fdi)
# nfs4_getfacl acl-dir

# file: acl-dir/
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdi:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

User1 tiene un directorio que hereda solo la ACL. En un subdirectorio creado debajo del elemento primario, la ACL se hereda, pero en un archivo debajo del elemento primario, no lo es.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file 
                       << ACL missing
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User2 tiene una marca de herencia de archivos y directorios. Como resultado, los archivos y directorios debajo de un directorio con esa entrada ACE heredan la ACL, pero los archivos no heredan la marca.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy << no flag
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User3 solo tiene una marca de herencia de archivo. Como resultado, solo los archivos situados debajo del directorio con esa entrada ACE heredan la ACL, pero no heredan la marca, ya que solo se puede aplicar a las ACE de directorio.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

Cuando se establece una marca "no-propogate" (n) en una ACL, las marcas se borran en las creaciones de directorio posteriores debajo del elemento primario. En el ejemplo siguiente, tiene user2establecida la marca n. Como resultado, el subdirectorio borra las marcas heredadas de esa entidad de seguridad y los objetos creados debajo de ese subdirectorio no heredan la ACE de user2.

#  nfs4_getfacl /mnt/acl-dir

# file: /mnt/acl-dir
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdn:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

#  nfs4_getfacl inherit-dir/

# file: inherit-dir/
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A::user2@CONTOSO.COM:rwaDxtTnNcCy << flag cleared
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# mkdir subdir
# nfs4_getfacl subdir

# file: subdir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
<< ACL not inherited
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

Heredar marcas es una manera de administrar más fácilmente las ACL de NFSv4.x, lo que le impide establecer explícitamente una ACL cada vez que necesite una.

Marcas administrativas

Las marcas administrativas de las ACL NFSv4.x son marcas especiales que solo se usan con los tipos de ACL Audit y Alarm. Estas marcas definen los intentos de acceso correctos (S) o error (F) para realizar acciones.

Azure NetApp Files admite configuración marcas administrativas para los ACE de auditoría, pero los ACE no funcionan. Además, los ACE de alarma no se admiten en Azure NetApp Files.

Entidades de seguridad de grupo y usuarios de NFSv4.x

Con las ACL NFSv4.x, las entidades de seguridad de usuario y grupo definen los objetos específicos a los que debe aplicarse una ACE. Por lo general, las entidades de seguridad siguen un formato de name@ID-DOMAIN-STRING.COM. La parte de “nombre” de una entidad de seguridad puede ser un usuario o grupo, pero ese usuario o grupo debe poder resolverse en Azure NetApp Files a través de la conexión del servidor LDAP al especificar el dominio de identificador NFSv4.x. Si Azure NetApp Files no puede resolver el name@domain, la operación de ACL produce un error de “argumento no válido”.

# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument

Puede comprobar en Azure NetApp Files si se puede resolver un nombre mediante la lista de identificadores de grupo LDAP. Vaya a soporte técnico y solución de problemas lista de identificadores de grupo LDAP.

Acceso de usuarios y grupos locales a través de ACL nfSv4.x

Los usuarios y grupos locales también se pueden usar en una ACL NFSv4.x si solo se especifica el identificador numérico en la ACL. Los nombres de usuario o los identificadores numéricos con un identificador de dominio especificado producen un error.

Por ejemplo:

# nfs4_setfacl -a A:fdg:3003:rwaxtTnNcCy NFSACL
# nfs4_getfacl NFSACL/
A:fdg:3003:rwaxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rwaDxtTnNcy
A::EVERYONE@:rwaDxtTnNcy

# nfs4_setfacl -a A:fdg:3003@CONTOSO.COM:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

# nfs4_setfacl -a A:fdg:users:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

Cuando se establece una ACL de grupo o usuario local, cualquier usuario o grupo que corresponda al identificador numérico de la ACL recibe acceso al objeto. En el caso de las ACL de grupo local, un usuario pasa sus pertenencias a grupos a Azure NetApp Files. Si el identificador numérico del grupo con acceso al archivo a través de la solicitud del usuario se muestra al servidor NFS de Azure NetApp Files, se permite el acceso según la ACL.

Las credenciales que se pasan del cliente al servidor se pueden ver a través de una captura de paquetes como se muestra a continuación.

Imagen que muestra la captura de paquetes de ejemplo con credenciales.

Advertencias:

  • El uso de usuarios y grupos locales para ACL significa que todos los clientes que acceden a los archivos o carpetas deben tener identificadores de usuario y grupo coincidentes.
  • Cuando se usa un identificador numérico para una ACL, Azure NetApp Files confía implícitamente en que la solicitud entrante es válida y que el usuario que solicita acceso es quien dice que son y son miembros de los grupos de los que reclaman ser miembros. Un usuario o un grupo numérico se puede suplantar si un actor incorrecto conoce el identificador numérico y puede acceder a la red mediante un cliente con la capacidad de crear usuarios y grupos localmente.
  • Si un usuario es miembro de más de 16 grupos, cualquier grupo después del decimosexto grupo (en orden alfanumérico) se deniega el acceso al archivo o carpeta, a menos que se use LDAP y compatibilidad con grupos extendidos.
  • Se recomienda encarecidamente LDAP y cadenas de nombre name@domain completas al usar ACL NFSv4.x para mejorar la capacidad de administración y la seguridad. Un repositorio de usuarios y grupos administrados centralmente es más fácil de mantener y más difícil de suplantar, lo que hace que el acceso de usuarios no deseados sea menos probable.

Dominio de identificador NFSv4.x

El dominio de identificador es un componente importante de la entidad de seguridad, donde un dominio de identificador debe coincidir tanto en el cliente como en Azure NetApp Files para los nombres de usuario y grupo (en concreto, raíz) para mostrarse correctamente en las propiedades de archivos o carpetas.

Azure NetApp Files tiene como valor predeterminado el dominio de identificador NFSv4.x en la configuración del dominio DNS del volumen. Los clientes NFS también tienen como valor predeterminado el dominio DNS del dominio de identificador NFSv4.x. Si el dominio DNS del cliente es diferente del dominio DNS de Azure NetApp Files, se produce una discrepancia. Al enumerar permisos de archivo con comandos como ls, los usuarios o grupos aparecen como “nadie".

Cuando se produce una discrepancia de dominio entre el cliente NFS y Azure NetApp Files, compruebe si hay errores similares a los registros de cliente:

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'

El dominio de identificador del cliente NFS se puede invalidar mediante la configuración de“Dominio” del archivo’/etc/idmapd.conf. Por ejemplo: Domain = CONTOSO.COM.

Azure NetApp Files también le permite cambiar el dominio de identificador NFSv4.1. Para más información, vea Configuración de dominio de identificador NFSv4.1 para Azure NetApp Files.

Permisos NFSv4.x

Los permisos NFSv4.x son la manera de controlar qué nivel de acceso tiene una entidad de seguridad de grupo o usuario específica en un archivo o carpeta. Los permisos en NFSv3 solo permiten niveles de lectura, escritura y ejecución (rwx) de definición de acceso, pero NFSv4.x proporciona una serie de otros controles de acceso pormenorizados como una mejora en los bits de modo NFSv3.

Hay 13 permisos que se pueden establecer para los usuarios y 14 permisos que se pueden establecer para grupos.

Carta de permiso Permiso concedido
r Leer archivos y carpetas de datos o listas
t Escritura de datos/creación de archivos y carpetas
a Anexar datos o crear subdirectorios
x Ejecutar archivos o atravesar directorios
d Eliminación de directorios y archivos
D Eliminar subdirectorios (solo directorios)
t Atributos de lectura (GETATTR)
T Atributos de escritura (SETATTR/chmod)
n Leer atributos con nombre
N Escribir atributos con nombre
c Leer ACL
C Escritura de ACL
o Propietario de escritura (chown)
y E/S sincrónica

Cuando se establecen los permisos de acceso, una entidad de seguridad de usuario o grupo se adhiere a esos derechos asignados.

Ejemplos de permisos NFSv4.x

En los ejemplos siguientes se muestra cómo funcionan los distintos permisos con diferentes escenarios de configuración.

Usuario con acceso de lectura (solo r)

Con el acceso de solo lectura, un usuario puede leer atributos y datos, pero se deniega cualquier acceso de escritura (datos, atributos, propietario).

A::user1@CONTOSO.COM:r

sh-4.2$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 12 12:41 .
drwxr-xr-x 3 root root 4096 Jul 12 12:09 ..
-rw-r--r-- 1 root root    0 Jul 12 12:41 file
drwxr-xr-x 2 root root 4096 Jul 12 12:31 subdir
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ chown user1 file
chown: changing ownership of ‘file’: Operation not permitted
sh-4.2$ nfs4_setfacl -e /mnt/acl-dir/inherit-dir
Failed setxattr operation: Permission denied
sh-4.2$ rm file
rm: remove write-protected regular empty file ‘file’? y
rm: can't remove ‘file’: Permission denied
sh-4.2$ cat file
Test text

Usuario con acceso de lectura (r) y atributos de escritura (T)

En este ejemplo, los permisos del archivo se pueden cambiar debido al permiso de atributos de escritura (T), pero no se puede crear ningún archivo, ya que solo se permite el acceso de lectura. Esta configuración muestra el tipo de controles granulares que pueden proporcionar las ACL NFSv4.x.

A::user1@CONTOSO.COM:rT

sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:23 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
-rw-r--r--  1 root     root      10 Jul 12 16:22 file
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rw-r--r--  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ chmod 777 user1-file
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:41 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rwxrwxrwx  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ rm user1-file
rm: can't remove ‘user1-file’: Permission denied

Traducción de bits de modo a permisos de ACL NFSv4.x

Cuando un chmod se ejecuta un objeto con ACL nfSv4.x asignadas, se actualiza una serie de ACL del sistema con nuevos permisos. Por ejemplo, si los permisos se establecen en 755, los archivos ACL del sistema se actualizan. En la tabla siguiente se muestra a qué se traduce cada valor numérico de un bit en los permisos de ACL nfSv4.

Vea permisos NFSv4.x para obtener una tabla que describa todos los permisos.

Numérico de bits de modo Permisos NFSv4.x correspondientes
1 – ejecutar (x) Ejecutar, leer atributos, leer ACL, E/S de sincronización (xtcy)
2 – escritura (w) Escritura, anexión de datos, atributos de lectura, atributos de escritura, atributos con nombre de escritura, ACL de lectura, E/S de sincronización (watTNcy)
3 – escritura/ejecución (wx) Escritura, anexión de datos, ejecución, atributos de lectura, atributos de escritura, atributos con nombre de escritura, ACL de lectura, E/S de sincronización (waxtTNcy)
4 – lectura (r) Leer, leer atributos, leer atributos con nombre, leer ACL, E/S de sincronización (rtncy)
5 – lectura/ejecución (rx) Leer, ejecutar, leer atributos, leer atributos con nombre, leer ACL, E/S de sincronización (rxtncy)
6 – lectura y escritura (rw) Leer, escribir, anexar datos, leer atributos, escribir atributos, leer atributos con nombre, escribir atributos con nombre, leer ACL, E/S de sincronización (rwatTnNcy)
7 – lectura,escritura/ejecución (rwx) Control total o todos los permisos

Funcionamiento de las ACL de NFSv4.x con Azure NetApp Files

Azure NetApp Files admite ACL NFSv4.x de forma nativa cuando un volumen tiene NFSv4.1 habilitado para el acceso. No hay nada que habilitar en el volumen para la compatibilidad con ACL, pero para que las ACL nfSv4.1 funcionen mejor, se necesita un servidor LDAP con usuarios y grupos UNIX para asegurarse de que Azure NetApp Files puede resolver las entidades de seguridad establecidas en las ACL de forma segura. Los usuarios locales se pueden usar con ACL nfSv4.x, pero no proporcionan el mismo nivel de seguridad que las ACL usadas con un servidor LDAP.

Hay consideraciones que debe tener en cuenta con la funcionalidad de ACL en Azure NetApp Files.

Herencia de ACL

En Azure NetApp Files, las marcas de herencia de ACL se pueden usar para simplificar la administración de ACL con ACL NFSv4.x. Cuando se establece una marca de herencia, las ACL de un directorio primario se pueden propagar a subdirectorios y archivos sin interacción adicional. Azure NetApp Files implementa comportamientos de herencia de ACL estándar según RFC-7530.

Denegación de ACE

Los ACE de denegación en Azure NetApp Files se usan para restringir explícitamente que un usuario o grupo acceda a un archivo o carpeta. Se puede definir un subconjunto de permisos para proporcionar controles granulares sobre la ACE de denegación. Estos operan en los métodos estándar mencionados en RFC-7530.

Conservación de ACL

Cuando se realiza un chmod en un archivo o carpeta de Azure NetApp Files, todos los ACE existentes se conservan en la ACL que no sean los ACE del sistema (OWNER@, GROUP@, EVERYONE@). Esos permisos ACE se modifican según lo definido por los bits de modo numérico definidos por el comando chmod. Solo se pueden cambiar los ACE que se modifican o quitan manualmente a través del comando nfs4_setfacl.

Comportamientos de ACL de NFSv4.x en entornos de protocolo dual

El protocolo dual hace referencia al uso de SMB y NFS en el mismo volumen de Azure NetApp Files. Los controles de acceso de protocolo dual se determinan mediante el estilo de seguridad que usa el volumen, pero la asignación de nombres de usuario garantiza que los usuarios de Windows y los usuarios de UNIX que se asignen correctamente entre sí tengan los mismos permisos de acceso a los datos.

Cuando las ACL nfSv4.x están en uso en volúmenes de estilo de seguridad de UNIX, se pueden observar los siguientes comportamientos al usar volúmenes de protocolo dual y acceder a datos de clientes SMB.

  • Los nombres de usuario de Windows deben asignarse correctamente a los nombres de usuario de UNIX para una resolución de control de acceso adecuada.
  • En volúmenes de estilo de seguridad de UNIX (donde se aplicarían ACL nfSv4.x), si no existe ningún usuario UNIX válido en el servidor LDAP para que un usuario de Windows se asigne, se usa un usuario UNIX predeterminado llamado pcuser (con uid numeric 65534) para la asignación.
  • Los archivos escritos con usuarios de Windows sin ninguna asignación de usuario UNIX válida se muestran como propiedad del identificador numérico 65534, que corresponde a “nfsnobody” o “nobody” nombre de usuario en clientes Linux de montajes NFS. Esto es diferente del identificador numérico 99, que normalmente se ve con problemas de dominio de identificador NFSv4.x. Para comprobar el identificador numérico en uso, use el comando ls -lan.
  • Los archivos con propietarios incorrectos no proporcionan resultados esperados de bits de modo UNIX ni de ACL NFSv4.x.
  • Las ACL NFSv4.x se administran desde clientes NFS. Los clientes SMB no pueden ver ni administrar ACL NFSv4.x.

Impacto de Umask con ACL NFSv4.x

ACL NFSv4 proporcionan la capacidad de ofrecer herencia de ACL. La herencia de ACL significa que los archivos o carpetas creados debajo de objetos con ACL NFSv4 establecidos pueden heredar las ACL en función de la configuración de la marca de herencia de ACL.

Umask se usa para controlar el nivel de permiso en el que se crean archivos y carpetas en un directorio. De forma predeterminada, Azure NetApp Files permite que umask invalide las ACL heredadas, que es el comportamiento esperado según RFC-7530.

Para obtener más información, vea umask.

Comportamiento de Chmod/chown con ACL NFSv4.x

En Azure NetApp Files, puede usar los comandos change ownership (chown) y change mode bit (chmod) para administrar los permisos de archivo y directorio en NFSv3 y NFSv4.x.

Cuando se usan ACL NFSv4.x, los controles más granulares aplicados a archivos y carpetas reducen la necesidad de comandos chmod. Chown todavía tiene un lugar, ya que las ACL NFSv4.x no asignan propiedad.

Cuando chmod se ejecuta en Azure NetApp Files en archivos y carpetas con ACL NFSv4.x aplicadas, los bits de modo se cambian en el objeto. Además, se modifica un conjunto de ACE del sistema para reflejar esos bits de modo. Si se quitan los ACE del sistema, se borran los bits del modo. A continuación se muestran ejemplos y una descripción más completa en la sección sobre ACE del sistema.

Cuando chown se ejecuta en Azure NetApp Files, se puede modificar el propietario asignado. La propiedad del archivo no es tan crítica cuando se usan ACL NFSv4.x como cuando se usan bits de modo, ya que las ACL se pueden usar para controlar los permisos de maneras que los conceptos básicos de propietario, grupo o todos los usuarios no podían. Chown en Azure NetApp Files solo se puede ejecutar como raíz (ya sea como raíz o mediante sudo), ya que los controles de exportación están configurados para permitir que solo la raíz realice cambios de propiedad. Dado que esto se controla mediante una regla de directiva de exportación predeterminada en Azure NetApp Files, las entradas de ACL NFSv4.x que permiten modificaciones de propiedad no se aplican.

# su user1
# chown user1 testdir
chown: changing ownership of ‘testdir’: Operation not permitted
# sudo chown user1 testdir
# ls -la | grep testdir
-rw-r--r--  1 user1    root     0 Jul 12 16:23 testdir

La regla de directiva de exportación del volumen se puede modificar para cambiar este comportamiento. En el menú Directiva de exportación para el volumen, modifique modo Chown a "sin restricciones."

Captura de pantalla del menú de exportación de directiva cambiando el modo chown a sin restricciones.

Una vez modificado, los usuarios que no sean raíz pueden cambiar la propiedad si tienen derechos de acceso adecuados. Esto requiere el permiso ACL “Take Ownership” NFSv4.x (designado por la letra “o”). La propiedad también se puede cambiar si el usuario que cambia la propiedad posee actualmente el archivo o la carpeta.

A::user1@contoso.com:rwatTnNcCy  << no ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
chown: changing ownership of 'newfile3': Permission denied

A::user1@contoso.com:rwatTnNcCoy  << with ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
user1@ubuntu:/mnt/testdir$ ls -la
total 8
drwxrwxrwx 2 user2 root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root  root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root  root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 user1 4294967294    0 Jul 14 16:31 newfile3

ACL del sistema

En cada ACL, hay una serie de ACE del sistema: OWNER@, GROUP@, EVERYONE@. Por ejemplo:

A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

Estos ACE corresponden a los permisos de bits de modo clásico que vería en NFSv3 y están directamente asociados a esos permisos. Cuando se ejecuta un chmod en un objeto, estas ACL del sistema cambian para reflejar esos permisos.

# nfs4_getfacl user1-file

# file: user1-file
A::user1@CONTOSO.COM:rT
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

# chmod 755 user1-file

# nfs4_getfacl user1-file

# file: user1-file
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rxtncy

Si se quitan esos ACE del sistema, la vista de permisos cambia de modo que los bits de modo normal (rwx) se muestran como guiones.

# nfs4_setfacl -x A::OWNER@:rwaxtTnNcCy user1-file
# nfs4_setfacl -x A:g:GROUP@:rxtncy user1-file
# nfs4_setfacl -x A::EVERYONE@:rxtncy user1-file
# ls -la | grep user1-file
----------  1 user1 group1     0 Jul 12 16:23 user1-file

Quitar ACL del sistema es una manera de proteger aún más los archivos y carpetas, ya que solo las entidades de seguridad de usuario y grupo de la ACL (y raíz) pueden acceder al objeto. La eliminación de ACE del sistema puede interrumpir las aplicaciones que dependen de las vistas de bits del modo para la funcionalidad.

Comportamiento del usuario raíz con ACL NFSv4.x

El acceso raíz con ACL NFSv4.x no se puede limitar a menos que raíz se aplaste. El aplastamiento de la raíz es donde se configura una regla de directiva de exportación en la que la raíz se asigna a un usuario anónimo para limitar el acceso. El acceso raíz se puede configurar desde el menú de Directiva de exportación de un volumen cambiando la regla de directiva de Acceso raíz a desactivado.

Para configurar el aplastamiento raíz, vaya al menú directiva de exportación en el volumen y, a continuación, cambie “Acceso raíz” a “desactivado” para la regla de directiva.

Captura de pantalla del menú de exportación de directiva con acceso raíz desactivado.

El efecto de deshabilitar el acceso raíz aplasta a usuarios anónimos nfsnobody:65534. Después, el acceso raíz no puede cambiar la propiedad.

root@ubuntu:/mnt/testdir# touch newfile3
root@ubuntu:/mnt/testdir# ls -la
total 8
drwxrwxrwx 2 user2  root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root   root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1  root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root   root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 nobody 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# ls -lan
total 8
drwxrwxrwx 2  1002          0 4096 Jul 14 16:31 .
drwxrwxrwx 5     0          0 4096 Jul 13 13:46 ..
-rw-r--r-- 1  1001          0    0 Jul 14 15:45 newfile
-rw-r--r-- 1     0          0    0 Jul 14 15:52 newfile2
-rw-r--r-- 1 65534 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# chown root newfile3
chown: changing ownership of 'newfile3': Operation not permitted

Como alternativa, en entornos de protocolo dual, las ACL NTFS se pueden usar para limitar de forma granular el acceso raíz.

Pasos siguientes