Los permisos de bit de modo solo cubren al propietario, al grupo y a todos los demás en la semántica, lo que significa que no hay controles de acceso de usuario granulares disponibles para NFSv3 básico. Google Cloud NetApp Volumes no admite listas de control de acceso POSIX, ni atributos extendidos (como chattr), por lo que las listas de control de acceso granulares solo son posibles en los siguientes casos con NFSv3:

Ambos métodos requieren una conexión LDAP para la gestión de identidades de UNIX y que se rellene información válida de usuarios y grupos de UNIX (consulte la sección "“LDAP”") y que solo están disponibles con instancias de NetApp Volumes-Performance. Para utilizar volúmenes de estilo de seguridad NTFS con NFS, debe utilizar el protocolo dual (SMB y NFSv3) o el protocolo doble (SMB y NFSv4.1), incluso si no se realiza ninguna conexión SMB. Para utilizar NFSv4,1 ACL con NFSv3 montajes, debe seleccionar Both (NFSv3/NFSv4.1) como tipo de protocolo.

Los bits del modo UNIX normal no proporcionan el mismo nivel de granularidad en permisos que proporcionan las ACL de NTFS o NFSv4.x. En la siguiente tabla, se compara la granularidad de permisos entre bits del modo NFSv3 y ACL de NFSv4.1. Para obtener más información sobre las ACL de NFSv4.1, consulte "Nfs4_acl - Listas de control de acceso de NFSv4".

Por último, la pertenencia a grupos de NFS (tanto en NFSv3 COMO EN NFSV4.x) está limitada a un máximo predeterminado de 16 para AUTH_SYS según los límites de paquetes RPC. NFS Kerberos proporciona hasta 32 grupos y las ACL de NFSv4 eliminan la limitación a través de ACL granulares de usuarios y grupos (hasta 1024 entradas por ACE).

Además, Google Cloud NetApp Volumes proporciona compatibilidad de grupos ampliada para ampliar el número máximo de grupos compatibles hasta 32 TB. Esto requiere una conexión LDAP a un servidor LDAP que contenga identidades de grupo y de usuario UNIX válidas. Para obtener más información sobre cómo configurar esto, consulte "Crear y gestionar volúmenes de NFS" en la documentación de Google.

Con NFSv3, el cliente y el servidor nunca tienen que confirmar que el usuario que intenta leer o escribir con un ID numérico es un usuario válido; sólo es de confianza implícita. Esto abre el sistema de archivos hasta posibles infracciones simplemente falsificar cualquier ID numérico. Para evitar agujeros de seguridad como este, hay algunas opciones disponibles para Google Cloud NetApp Volumes.

En última instancia, la seguridad de NFS se limita a qué versión del protocolo utiliza que ofrece. NFSv3, aunque tiene un rendimiento general superior al de NFSv4.1, no proporciona el mismo nivel de seguridad.

Debido a las funciones de seguridad adicionales de NFSv4.1, existen algunas dependencias externas implicadas que no fueron necesarias para utilizar NFSv3 (de forma similar a cómo requiere SMB dependencias como Active Directory).

Google Cloud NetApp Volumes ofrece compatibilidad con las listas de control de acceso (ACL) de NFSv4.x, que ofrecen distintas ventajas con respecto a los permisos normales de estilo POSIX, como las siguientes:

Las ACL de NFSv4 son distintas de las de ACL de nivel de archivo de Windows (ACL de NTFS), pero llevan funciones similares. Sin embargo, en los entornos NAS multiprotocolo, si hay ACL de NFSv4.1 y utiliza acceso de doble protocolo (NFS y SMB en los mismos conjuntos de datos), los clientes que utilicen SMB2.0 y versiones posteriores no podrán ver ni gestionar ACL desde pestañas de seguridad de Windows.

Como referencia, se definen los siguientes términos:

Cuando un cliente establece una ACL de NFSv4,1 en un archivo durante una operación SETATTR, los volúmenes de Google Cloud NetApp establecen esa ACL en el objeto, reemplazando cualquier ACL existente. Si no hay ACL en un archivo, los permisos de modo en el archivo se calculan a partir de OWNER@, GROUP@ y EVERYONE@. Si hay algún bit SUID/SGID/STICKY existente en el archivo, no se verán afectados.

Cuando un cliente obtiene una ACL de NFSv4,1 en un archivo durante el transcurso de una OPERACIÓN GETATTR, Google Cloud NetApp Volumes lee la ACL de NFSv4,1 asociada con el objeto, crea una lista de ACL y devuelve la lista al cliente. Si el archivo tiene una ACL de NT o bits de modo, se crea una ACL a partir de bits de modo y se devuelve al cliente.

Se deniega el acceso si EXISTE UNA ACE DENEGADA en la ACL; el acceso se concede si existe una ACE DE PERMISO. Sin embargo, también se deniega el acceso si ninguno de los ACE está presente en el ACL.

Un descriptor de seguridad consiste en una ACL de seguridad (SACL) y una ACL discrecional (DACL). Cuando NFSv4.1 interactúa con CIFS/SMB, el DACL se asigna de uno a uno con NFSv4 y CIFS. El DACL consta de LOS ACs PERMITIR Y DENEGAR.

Si es un básico chmod Se ejecuta en un archivo o carpeta con conjuntos de ACL de NFSv4.1, se conservan las ACL de usuario y grupo existentes, pero se modifican las ACL de PROPIETARIO@, GRUPO@ y TODOS@ predeterminadas.

Un cliente que utilice las ACL de NFSv4.1 puede definir y ver ACL de archivos y directorios en el sistema. Cuando se crea un archivo o subdirectorio nuevo en un directorio que tiene una ACL, ese objeto hereda todos los ACE de la ACL que se han etiquetado con el correspondiente "indicadores de herencia".

Si un archivo o directorio tiene una ACL de NFSv4.1, esa ACL se utiliza para controlar el acceso, independientemente de qué protocolo se utilice para acceder al archivo o directorio.

Los archivos y directorios heredan los ACE de las ACL de NFSv4 en directorios principales (posiblemente con las modificaciones adecuadas) siempre que se hayan etiquetado los ACE con las marcas de herencia correctas.

Cuando se crea un archivo o directorio como resultado de una solicitud de NFSv4, la ACL del archivo o directorio resultante depende de si la solicitud de creación de archivos incluye una ACL o solo permisos de acceso estándar a archivos UNIX. La ACL también depende de si el directorio primario tiene una ACL.

Los permisos de ACL de NFSv4.1 utilizan una serie de valores de letras mayúsculas y minúsculas (como rxtncy) para controlar el acceso. Para obtener más información acerca de estos valores de letra, consulte "CÓMO: Utilizar NFSv4 ACL".

"Las ACL de NFSv4 proporcionan la capacidad de ofrecer herencia de ACL". La herencia de ACL significa que los archivos o carpetas creados debajo de los objetos con conjuntos de ACL de NFSv4.1 pueden heredar las ACL según la configuración de "Indicador de herencia de ACL".

"Umask" se utiliza para controlar el nivel de permiso en el que se crean archivos y carpetas en un directorio sin interacción del administrador. De forma predeterminada, Google Cloud NetApp Volumes permite que umask anule las ACL heredadas, que es el comportamiento esperado según "RFC 5661" .

Las ACL de NFSv4.1 tienen formato específico. El ejemplo siguiente es un conjunto ACE en un archivo:

El ejemplo anterior sigue las directrices de formato ACL de:

Tipo de A significa “permitir”. Los indicadores heredar no se establecen en este caso, porque el principal no es un grupo y no incluye la herencia. Además, como ACE no es una entrada DE AUDITORÍA, no es necesario establecer los indicadores de auditoría. Para obtener más información sobre las ACL de NFSv4.1, consulte "http://linux.die.net/man/5/nfs4_acl".

Si la ACL de NFSv4.1 no se establece correctamente (o el cliente y el servidor no pueden resolver una cadena de nombre), es posible que la ACL no se comporte como se espera o que el cambio de ACL no se pueda aplicar y generar un error.

Los errores de muestra son los siguientes:

Los permisos de NFSv4.1 pueden incluir atributos DE DENEGACIÓN explícitos para EL PROPIETARIO, EL GRUPO Y TODOS. Esto se debe a que las ACL de NFSv4.1 son denegadas por defecto, lo que significa que si un ACE no concede explícitamente una ACL, se deniega. Los atributos DE DENEGACIÓN explícita anulan cualquier ACE de ACCESO, explícita o no.

DENEGAR ACE se establece con una etiqueta de atributo de D.

En el siguiente ejemplo, SE permite a GROUP@ todos los permisos de lectura y ejecución, pero se le deniega todo el acceso de escritura.

DENEGAR ACs debe evitarse siempre que sea posible porque pueden ser confusos y complicados; PERMITIR que las ACL que no están definidas explícitamente se deniegan implícitamente. Cuando SE establecen LAS ACE DENEGADAS, es posible que se deniegue el acceso a los usuarios cuando esperan que se les conceda el acceso.

El conjunto anterior de ACE es equivalente a 755 bits de modo, lo que significa:

Sin embargo, incluso si los permisos se ajustan al equivalente de 775, se puede denegar el acceso debido a LA DENEGACIÓN explícita establecida en TODOS.

NFSv4.1 aprovecha la lógica de asignación de dominio de ID como capa de seguridad para ayudar a verificar que un usuario que intenta acceder a un montaje de NFSv4.1 es realmente lo que afirman que es. En estos casos, el nombre de usuario y el nombre de grupo que proviene del cliente NFSv4,1 añade una cadena de nombre y la envía a la instancia de Google Cloud NetApp Volumes. Si esa combinación de nombre de usuario/grupo y cadena de ID no coincide, el usuario y/o grupo se aplaza con el usuario Nadie especificado por defecto en el /etc/idmapd.conf archivo del cliente.

Esta cadena de ID es un requisito para la observancia correcta de los permisos, especialmente cuando se utilizan las ACL de NFSv4.1 y/o Kerberos. Como resultado, las dependencias del servidor del servicio de nombres, como los servidores LDAP, son necesarias para garantizar la coherencia entre los clientes y los volúmenes de Google Cloud NetApp con el fin de lograr una resolución adecuada de la identidad de los nombres de usuarios y grupos.

Google Cloud NetApp Volumes usa un valor de nombre de dominio de ID predeterminado estático de defaultv4iddomain.com. Los clientes NFS utilizan por defecto el nombre de dominio DNS para su configuración de nombre de dominio ID, pero puede ajustar manualmente el nombre de dominio ID en /etc/idmapd.conf.

Si LDAP está habilitado en Google Cloud NetApp Volumes, Google Cloud NetApp Volumes automatiza el dominio de ID de NFS para cambiar al configurado para el dominio de búsqueda en DNS, y los clientes no tendrán que modificarse a menos que utilicen nombres de búsqueda de dominio DNS diferentes.

Cuando los volúmenes de NetApp de Google Cloud pueden resolver un nombre de usuario o un nombre de grupo en archivos locales o LDAP, se utiliza la cadena de dominio y los ID de dominio sin coincidencia se reducen a nadie. Si Google Cloud NetApp Volumes no puede encontrar un nombre de usuario o un nombre de grupo en los archivos locales o LDAP, se utiliza el valor de ID numérico y el cliente NFS resuelve el nombre correctamente (es similar al comportamiento de NFSv3).

Sin cambiar el dominio de ID de NFSv4,1 del cliente para que coincida con lo que usa el volumen de volúmenes de NetApp de Google Cloud, se observará el siguiente comportamiento:

A continuación se muestran los resultados de la situación anterior:

Cuando los dominios de ID de cliente y servidor coinciden, así es como el mismo aspecto del listado de archivos:

Para obtener más información acerca de este problema y cómo resolverlo, consulte la sección “NFSv4.1 y el usuario/grupo nadie.”

Si piensa utilizar Kerberos con NFS, debe disponer de lo siguiente con Google Cloud NetApp Volumes:

Uno de los problemas más comunes que se ven con una configuración de NFSv4.1 es cuando se muestra un archivo o una carpeta en un listado mediante ls como propiedad de la user:group combinación de nobody:nobody.

Por ejemplo:

Y el ID numérico es 99.

En algunos casos, es posible que el archivo muestre el propietario correcto pero nobody como grupo.

¿Quién no es nadie?

La nobody El usuario de NFSv4.1 es diferente del nfsnobody usuario. Puede ver cómo un cliente NFS ve cada usuario ejecutando el id comando:

Con NFSv4.1, el nobody user es el usuario predeterminado definido por idmapd.conf file y puede definirse como cualquier usuario que desee utilizar.

¿Por qué sucede esto?

Puesto que la seguridad mediante la asignación de cadenas de nombres es un conjunto de claves de las operaciones de NFSv4.1, el comportamiento predeterminado cuando una cadena de nombres no coincide correctamente es squash a ese usuario con uno que normalmente no tendrá acceso a los archivos y carpetas que pertenecen a usuarios y grupos.

Cuando vea nobody Para el usuario o el grupo de los listados de archivos, esto generalmente significa que hay algo configurado para NFSv4.1. Aquí puede entrar en juego la sensibilidad del caso.

Por ejemplo, si user1@CVSDEMO.LOCAL (uid 1234, gid 1234) accede a una exportación, los volúmenes de NetApp de Google Cloud deben poder encontrar user1@CVSDEMO.LOCAL (uid 1234, gid 1234). Si el usuario de Google Cloud NetApp Volumes es USER1@CVSDEMO.LOCAL, no coincidirá (User1 en mayúsculas frente a user1 en minúsculas). En muchos casos, puede ver lo siguiente en el archivo de mensajes del cliente:

El cliente y el servidor deben aceptar que un usuario es realmente quien dice ser, por lo que debe comprobar lo siguiente para asegurarse de que el usuario que ve tiene la misma información que el usuario que ve Google Cloud NetApp Volumes.

En prácticamente todos los casos, si te ves nobody en listas de usuarios y grupos de clientes, el problema es la traducción de ID de dominio de nombre de usuario o grupo entre los volúmenes de Google Cloud NetApp y el cliente NFS. Para evitar esta situación, utilice LDAP para resolver la información de usuarios y grupos entre clientes y Google Cloud NetApp Volumes.

Si utiliza NFSv4.1, hay una asignación de cadena de nombre que se realiza durante las operaciones de NFS, como se ha descrito anteriormente.

Además de utilizar /var/log/messages Para encontrar un problema con los ID de NFSv4, puede utilizar la "nfsidmap -l" Comando en el cliente NFS para ver los nombres de usuario que se han asignado correctamente al dominio de NFSv4.

Por ejemplo, se muestra el comando cuando un usuario que el cliente puede encontrar y los volúmenes de NetApp de Google Cloud acceden a un montaje de NFSv4.x:

Cuando un usuario que no se asigna correctamente al dominio de ID de NFSv4.1 (en este caso, netapp-user) intenta acceder al mismo montaje y toca un archivo, están asignados nobody:nobody, según lo esperado.

La nfsidmap -l salida muestra al usuario pcuser en la pantalla pero no netapp-user; éste es el usuario anónimo en nuestra regla de política de exportación (65534).