Guía de administración de Oracle Solaris ZFS

Capítulo 8 Uso de listas ACL para proteger archivos ZFS

Este capítulo proporciona información sobre cómo utilizar listas de control de acceso (ACL) para proteger los archivos ZFS. Las listas ACL proporcionan más permisos granulares que los permisos UNIX estándar.

Este capítulo se divide en las secciones siguientes:

Nuevo modelo de ACL de Solaris

Las versiones anteriores del sistema operativo Solaris admitían una implementación de ACL que se basaba principalmente en la especificación ACL de borrador POSIX. Estas clases de ACL se utilizan para proteger archivos UFS y se traducen de versiones de NFS anteriores a NFSv4.

NFSv4 es un nuevo modelo de ACL totalmente compatible que permite la interoperatividad entre clientes UNIX y que no son UNIX. La nueva implementación de ACL, tal como se indica en las especificaciones de NFSv4, aporta una semántica mucho más rica que las ACL del tipo NT.

Las diferencias principales del nuevo modelo de ACL son:

El modelo nuevo se basa en la especificación de NFSv4 y se parece a las ACL del tipo NT.
El nuevo modelo ofrece un conjunto mucho más granular de privilegios de acceso. Para obtener más información, consulte la Tabla 8–2.
Las listas ACL se definen y visualizan con los comandos chmod e ls, en lugar de los comandos setfacl y getfacl.
El modelo nuevo proporciona una mejor semántica de herencia para establecer la forma en que se aplican los privilegios de acceso del directorio a los subdirectorios, y así sucesivamente. Para obtener más información, consulte Herencia de ACL.

Los modelos de ACL proporcionan un control de acceso mucho más granular que los permisos de archivos estándar. De forma muy parecida a las ACL de borrador POSIX, las nuevas ACL disponen de varias entradas de control de acceso.

Las ACL basadas en borrador POSIX emplean una sola entrada para definir los permisos que se conceden y los que se deniegan. El nuevo modelo de ACL presenta dos clases de entradas de control de acceso que afectan a la comprobación de acceso: ALLOW y DENY. Así, a partir de una entrada de control de acceso que defina un conjunto de permisos no puede deducirse si se conceden o deniegan los permisos que no se hayan definido en dicha entrada.

La traducción entre las ACL de tipo NFSv4 y las de borrador POSIX se efectúa de la manera siguiente:

Si emplea una utilidad que tiene en cuenta ACL, por ejemplo uno de los comandos cp, mv, tar, cpio o rcp, para transferir archivos UFS con ACL a un sistema de archivos ZFS, las ACL de borrador POSIX se traducen a sus equivalentes del tipo NFSv4.
Algunas ACL de tipo NFSv4 se traducen a ACL de borrador POSIX. Si una ACL de tipo NFSv4 no se traduce a una ACL de borrador POSIX, en pantalla aparece un mensaje parecido al siguiente:
# cp -p filea /var/tmp cp: failed to set acl entries on /var/tmp/filea
Si crea un contenedor UFS tar o cpio con la opción de mantener ACL (tar -p o cpio -P) en un sistema que ejecuta una versión actual de Solaris, las ACL se pierden si el contenedor se extrae a un sistema que ejecuta una versión anterior de Solaris.

Se extraen todos los archivos con los modelos de archivos correctos, pero se omiten las entradas de ACL.
El comando ufsrestore es apto para restaurar datos en un sistema de archivos ZFS. Si los datos originales incluyen las ACL de borrador POSIX, se traducen a NFSv4 ACL.
Si intenta definir una ACL de tipo NFSv4 en un archivo UFS, en pantalla aparece un mensaje similar al siguiente:
chmod: ERROR: ACL type's are different

Si intenta definir una ACL de borrador POSIX en un archivo ZFS, en pantalla se muestran mensajes parecidos al siguiente:

# getfacl filea
File system doesn't support aclent_t style ACL's.
See acl(5) for more information on Solaris ACL support.

Para obtener información sobre otras limitaciones con las ACL y demás productos para copias de seguridad, consulte Cómo guardar datos de ZFS con otros productos de copia de seguridad.

Descripciones de la sintaxis para definir listas ACL

A continuación se detallan dos formatos básicos de ACL:

Sintaxis para definir ACL triviales

Una ACL se considera trivial en el sentido de que sólo representa las entradas de UNIX owner/group/other tradicionales.

chmod [options] A[index]{+|=}owner@ |group@ |everyone@: access-permissions/...[:inheritance-flags]: deny | allow archivo

chmod [options] A-owner@, group@, everyone@:access-permissions /...[:inheritance-flags]:deny | allow archivo ...

chmod [options] A[index]- archivo

Sintaxis para definir ACL no triviales

chmod [options] A[index]{+|=}user|group:name:access-permissions /...[:inheritance-flags]:deny | allow archivo

chmod [options] A-user|group:name:access-permissions /...[:inheritance-flags]:deny | allow archivo ...

chmod [options] A[index]- archivo

owner@, group@, everyone@: Identifica el tipo de entrada ACL de la sintaxis de ACL trivial. Para obtener una descripción de los tipos de entrada ACL, consulte la Tabla 8–1.
usuario o grupo: ID de entrada ACL=nombre de usuario o nombre de grupo: Identifica el tipo de entrada ACL de la sintaxis de ACL explícita. El tipo de entrada ACL user y group también debe contener el ID de entrada ACL, username o groupname. Para obtener una descripción de los tipos de entrada ACL, consulte la Tabla 8–1.
access-permissions/.../: Identifica los permisos de acceso que se conceden o deniegan. Para obtener una descripción de los permisos de acceso de ACL, consulte la Tabla 8–2.
inheritance-flags: Identifica una lista opcional de indicadores de herencia de ACL. Para obtener una descripción de los indicadores de herencia de ACL, consulte la Tabla 8–3.
deny | allow: Identifica si se conceden o deniegan los permisos de acceso.

En el ejemplo siguiente, el valor de ID de entrada ACL no es relevante:

group@:write_data/append_data/execute:deny

El ejemplo siguiente incluye un ID de entrada ACL porque en la ACL se incluye un usuario específico (tipo de entrada ACL).

0:user:gozer:list_directory/read_data/execute:allow

Cuando en pantalla se muestra una entrada de ACL, se parece al ejemplo siguiente:

2:group@:write_data/append_data/execute:deny

En este ejemplo, el 2, también denominado ID de índice, identifica la entrada ACL en la ACL más grande, que podría tener varias entradas para owner (propietario), UID específicos, group (grupo) y everyone (cualquiera). Se puede especificar el ID de índice con el comando chmod para identificar la parte de la ACL que desea modificar. Por ejemplo, el ID de índice 3 puede identificarse como A3 en la sintaxis del comando chmod de una forma similar a la siguiente:

chmod A3=user:venkman:read_acl:allow filename

Los tipos de entrada ACL, que son las representaciones de ACL de los propietarios, grupos, etc., se describen en la tabla siguiente.

Tabla 8–1 Tipos de entradas de ACL


Tipo de entrada de ACL	Descripción
`owner@`	Especifica el acceso que se concede al propietario del objeto.
`group@`	Especifica el acceso que se concede al grupo propietario del objeto.
`everyone@`	Especifica el acceso que se concede a cualquier usuario o grupo que no coincida con ninguna otra entrada de ACL.
`user`	Con un nombre de usuario, especifica el acceso que se concede a un usuario adicional del objeto. Esta entrada debe incluir el ID de entrada ACL, que contiene un `nombre_usuario` o `ID_usuario`. Si el valor no es un ID de usuario numérico o `nombre de usuario` válido, el tipo de entrada de ACL tampoco es válido.
`group`	Con un nombre de grupo, especifica el acceso que se concede a un grupo adicional del objeto. Esta entrada debe incluir el ID de entrada ACL, que contiene un `nombre de usuario` o `ID de grupo`. Si el valor no es un ID de grupo numérico o `nombre de grupo` válido, el tipo de entrada de ACL tampoco es válido.

En la tabla siguiente se describen los privilegios de acceso de ACL.

Tabla 8–2 Privilegios de acceso de ACL


Privilegio de acceso	Privilegio de acceso compacto	Descripción
`add_file`	`w`	Permiso para agregar un archivo nuevo a un directorio.
`add_subdirectory`	`p`	En un directorio, permiso para crear un subdirectorio.
`append_data`	`p`	Marcador de posición. Actualmente no se ha implementado.
`delete`	`d`	Permiso para eliminar un archivo.
`delete_child`	`D`	Permiso para eliminar un archivo o un directorio dentro de un directorio.
`execute`	`x`	Permiso para ejecutar un archivo o buscar en el contenido de un directorio.
`list_directory`	`r`	Permiso para resumir el contenido de un directorio.
`read_acl`	`c`	Permiso para leer la ACL (`ls`).
`read_attributes`	`a`	Permiso para leer los atributos básicos (no ACL) de un archivo. Los atributos de tipo stat pueden considerarse atributos básicos. Permitir este bit de la máscara de acceso significa que la entidad puede ejecutar `ls`(1) y `stat`(2).
`read_data`	`r`	Permiso para leer el contenido de un archivo.
`read_xattr`	`R`	Permiso para leer los atributos extendidos de un archivo o al buscar en el directorio de atributos extendidos del archivo.
`synchronize`	`s`	Marcador de posición. Actualmente no se ha implementado.
`write_xattr`	`W`	Permiso para crear atributos extendidos o escribir en el directorio de atributos extendidos. Si se concede este permiso a un usuario, el usuario puede crear un directorio de atributos extendidos para un archivo. Los permisos de atributo del archivo controlan el acceso al atributo por parte del usuario.
`write_data`	`w`	Permiso para modificar o reemplazar el contenido de un archivo.
`write_attributes`	`A`	Permiso para cambiar los sellos de fecha asociados con un archivo o directorio a un valor arbitrario.
`write_acl`	`C`	Permiso para escribir en la ACL o posibilidad de modificarla mediante el comando `chmod`.
`write_owner`	`o`	Permiso para cambiar el grupo o propietario del archivo. O posibilidad de ejecutar los comandos `chown` o `chgrp` en el archivo. Permiso para adquirir la propiedad de un archivo o para cambiar la propiedad del grupo de un archivo a un grupo al que pertenezca el usuario. Si desea cambiar la propiedad de grupo o archivo a un usuario o grupo arbitrario, se necesita el privilegio `PRIV_FILE_CHOWN`.

Herencia de ACL

La finalidad de utilizar la herencia de ACL es que los archivos o directorios que se creen puedan heredar las ACL que en principio deben heredar, pero sin prescindir de los permisos en el directorio superior.

De forma predeterminada, las ACL no se propagan. Si en un directorio se establece una ACL no trivial, no se heredará en ningún directorio posterior. Debe especificar la herencia de una ACL en un archivo o directorio.

En la tabla siguiente se describen los indicadores de herencia opcionales.

Tabla 8–3 Indicadores de herencia de ACL


Indicador de herencia	Indicador de herencia compacto	Descripción
`file_inherit`	`f`	La ACL se hereda del directorio superior, pero únicamente se aplica a los archivos del directorio.
`dir_inherit`	`d`	La ACL se hereda del directorio superior, pero únicamente se aplica a los subdirectorios del directorio.
`inherit_only`	`i`	La ACL se hereda del directorio superior, pero únicamente se aplica a los archivos y subdirectorios que se creen, no al directorio en sí. Para especificar lo que se hereda. se necesita el indicador `file_inherit`, `dir_inherit` o ambos.
`no_propagate`	`n`	La ACL se hereda sólo del directorio superior al contenido del primer nivel del directorio. Se excluye el contenido del segundo nivel o inferiores. Para especificar lo que se hereda se necesita el indicador `file_inherit`, `dir_inherit` o ambos.
`-`	N/D	Ningún permiso concedido.

Además, se puede establecer una directriz de herencia de ACL predeterminada del sistema de archivos más o menos estricta, mediante la propiedad del sistema de archivos aclinherit. Para obtener más información, consulte la siguiente sección.

Propiedades de ACL

Un sistema de archivos ZFS incluye dos modos de propiedades en relación con ACL.

aclinherit: propiedad que determina el comportamiento de la herencia de ACL. Puede tener los valores siguientes:
- discard: en los objetos nuevos, si se crea un archivo o directorio, no se heredan entradas de ACL. La ACL del archivo o directorio nuevo es igual a los permisos del archivo o directorio.
- noallow: en los objetos nuevos, sólo se heredan las entradas de ACL cuyo tipo de acceso sea deny.
- restricted: en los objetos nuevos, al heredarse una entrada de ACL se eliminan los permisos write_owner y write_acl.
- passthrough: si el valor de propiedad se configura como passthrough, los archivos se crean con permisos que determinan las entradas de control de acceso que se pueden heredar. Si no existen entradas de control de acceso que se puedan heredar y que afecten a los permisos, los permisos se configurarán de acuerdo con los solicitados desde la aplicación.
- passthrough-x : este valor de propiedad tiene la misma semántica que passthrough, excepto que cuando passthrough-x está habilitado, los archivos se crean con el permiso de ejecución (x), pero sólo si este permiso se ha establecido en el modo de creación de archivos y en un ACE heredable que afecta al modo.
El valor predeterminado de la propiedad aclinherit es restricted.
aclmode: esta propiedad modifica el comportamiento de ACL al crear un archivo por primera vez o si el comando chmod modifica los permisos de un archivo o directorio. Los valores posibles son:
- discard: se eliminan todas las entradas de ACL menos las que se necesiten para definir el modo del archivo o directorio.
- groupmask: se reducen los permisos de ACL de usuario o grupo para que no sean mayores que los permisos de grupo, a menos que se trate de una entrada de usuario cuyo ID de usuario sea idéntico al del propietario del archivo o directorio. Así, los permisos de ACL se reducen para que no superen los permisos del propietario.
- passthrough: durante el funcionamiento de chmod, las entradas de control de acceso que no sean owner@, group@ o everyone@ no se modifican de ningún modo. Las entradas de control de acceso con owner@, group@ o everyone@ están desactivadas para configurar el modo de archivo de acuerdo con lo solicitado por el funcionamiento de chmod.
groupmask es el valor predeterminado de la propiedad aclmode.

Establecimiento de las ACL en archivos ZFS

Al implementarse con ZFS, las ACL se componen de una matriz de entradas de ACL. ZFS proporciona un modelo de ACL puro en el que todos los archivos disponen de una ACL. Normalmente, las ACL son triviales en el sentido de que únicamente representan las entradas de UNIX owner/group/other tradicionales.

Si cambia los permisos del archivo, su ACL se actualiza en consonancia. Además, si elimina una ACL no trivial que concedía a un usuario acceso a un archivo o directorio, ese usuario quizá siga disponiendo de acceso gracias a los bits de permisos del archivo o directorio que conceden acceso al grupo o a todos los usuarios. Todas las decisiones de control de acceso se supeditan a los permisos representados en una ACL de archivo o directorio.

A continuación se proporcionan las reglas principales de acceso de ACL de un archivo ZFS:

ZFS procesa entradas de ACL en el orden que figuran en la ACL, de arriba abajo.
Sólo se procesan entradas de ACL que tengan a "alguien" que coincida con quien solicita acceso.
Una vez se concede un permiso allow, una entrada deny de ACL posterior no lo puede denegar en el mismo conjunto de permisos de ACL.
El permiso write_acl se concede de forma incondicional al propietario del archivo aunque el permiso se deniegue explícitamente. De lo contrario, se deniega cualquier permiso que no quede especificado.

Con permisos deny o cuando falta un permiso de acceso para un archivo, el subsistema de privilegios determina la solicitud de acceso que se concede al propietario del archivo o superusuario. Es un mecanismo para permitir que los propietarios de archivos siempre puedan acceder a sus archivos y que los superusuarios puedan modificar archivos en situaciones de recuperación.

Si en un directorio se establece una ACL no trivial, los directorios secundarios no heredan la ACL de manera automática. Si se establece una ACL no trivial y desea que la hereden los directorios secundarios, debe utilizar los indicadores de herencia de ACL. Para obtener más información, consulte la Tabla 8–3 y Establecimiento de herencia de ACL en archivos ZFS en formato detallado.

Al crear un archivo, y en función del valor umask, se aplica una ACL similar a la siguiente:

$ ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 14:09 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Cada categoría de usuario (owner@!, group@!, everyone@!) tiene dos entradas de ACL en este ejemplo. Una entrada es para los permisos deny y otra para los permisos allow.

A continuación se proporciona una descripción de la ACL de este archivo:

0:owner@: Se deniega al propietario el permiso de ejecución del archivo (execute:deny ).
1:owner@: El propietario puede leer y modificar el contenido del archivo ( read_data/write_data/append_data). También puede modificar atributos del archivo como indicaciones de hora, atributos extendidos y ACL (write_xattr/write_attributes /write_acl). Además, puede modificar la propiedad del archivo (write_owner:allow).
2:group@: Se deniegan al grupo permisos de modificación y ejecución del archivo (write_data/append_data/execute:deny).
3:group@: Se conceden al grupo permisos de lectura del archivo (read_data:allow ).
4:everyone@: Se deniegan a quien no sea propietario del archivo o miembro del grupo propietario los permisos de ejecución o modificación del contenido del archivo, y de modificación de sus atributos (write_data/append_data/write_xattr/execute/write_attributes/write_acl/write_owner:deny ).
5:everyone@: Se conceden a quien no sea propietario del archivo o miembro del grupo propietario permisos de lectura del archivo y de sus atributos (read_data/read_xattr/read_attributes/read_acl/synchronize:allow ). El permiso de acceso synchronize no está implementado en la actualidad.

Al crear un directorio, y en función del valor umask, se aplica una ACL de directorio predeterminada similar a la siguiente:

$ ls -dv dir.1
drwxr-xr-x   2 root     root           2 May 20 14:11 dir.1
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

A continuación se proporciona una descripción de esta ACL de directorio:

0:owner@: La lista de deny del propietario está vacía para el directorio (::deny).
1:owner@: El propietario puede leer y modificar el contenido del directorio (list_directory/read_data/add_file/write_data/add_subdirectory/append_data ), buscar en el contenido (execute) y modificar atributos del archivo como indicaciones de hora, atributos extendidos y ACL (write_xattr/write_attributes/write_acl). Además, puede modificar la propiedad del directorio (write_owner:allow).
2:group@: El grupo no puede agregar ni modificar contenido del directorio ( add_file/write_data/add_subdirectory/append_data:deny).
3:group@: El grupo puede agrupar y leer el contenido del directorio. Además, tiene permisos de ejecución para buscar en el contenido del directorio (list_directory/read_data/execute:allow).
4:everyone@: Se deniega a quien no sea propietario del archivo o miembro del grupo propietario el permiso de adición o modificación del contenido del directorio (add_file/write_data/add_subdirectory/append_data). Además se deniega el permiso para modificar atributos del directorio (write_xattr/write_attributes/write_acl/write_owner:deny).
5:everyone@: Se conceden a quien no sea propietario del archivo o miembro del grupo propietario permisos de lectura y ejecución del contenido del directorio y sus atributos (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow ). El permiso de acceso synchronize no está implementado en la actualidad.

Establecimiento y visualización de ACL en archivos ZFS en formato detallado

El comando chmod es válido para modificar las ACL de archivos ZFS. La sintaxis siguiente del comando chmod para modificar ACL utiliza especificación ACL para identificar el formato de la ACL. Para obtener una descripción de especificación ACL, consulte Descripciones de la sintaxis para definir listas ACL.

Adición de entradas de ACL
- Adición de una entrada de ACL para un usuario
  % chmod A+acl-specification filename
- Adición de una entrada de ACL mediante ID_índice
  % chmod Aindex-ID+acl-specification filename
  Esta sintaxis inserta la nueva entrada de ACL en la ubicación de ID_índice que se especifica.

Sustitución de una entrada de ACL

% chmod A=acl-specification filename

% chmod Aindex-ID=acl-specification filename

Eliminación de entradas de ACL
- Eliminación de una entrada de ACL mediante ID_índice
  % chmod Aindex-ID- filename
- Eliminación de una entrada de ACL por usuario
  % chmod A-acl-specification filename
- Eliminación de todas las entradas de control de acceso no triviales de un archivo
  % chmod A- filename

Para ver en pantalla información de ACL en modo detallado, se utiliza el comando ls -v. Por ejemplo:

# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 14:09 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Para obtener información sobre el uso del formato de ACL compacto, consulte Establecimiento y visualización de ACL en archivos ZFS en formato compacto.

Ejemplo 8–1 Modificación de ACL triviales en archivos ZFS

Esta sección proporciona ejemplos de cómo configurar y mostrar ACL triviales.

En el ejemplo siguiente, en file.1 hay una ACL trivial:

# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

En el ejemplo siguiente, se conceden permisos de write_data para group@:

# chmod A2=group@:append_data/execute:deny file.1
# chmod A3=group@:read_data/write_data:allow file.1
# ls -v file.1
-rw-rw-r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:append_data/execute:deny
     3:group@:read_data/write_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

En el ejemplo siguiente, los permisos de file.1 se establecen en 644.

# chmod 644 file.1
# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Ejemplo 8–2 Establecimiento de ACL no triviales en archivos ZFS

En esta sección se proporcionan ejemplos de establecimiento y visualización de ACL no triviales.

En el ejemplo siguiente, se agregan permisos de read_data/execute para el usuario gozer en el directorio test.dir:

# chmod A+user:gozer:read_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 May 20 15:09 test.dir
     0:user:gozer:list_directory/read_data/execute:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

En el ejemplo siguiente, se retiran los permisos de read_data/execute para el usuario gozer:

# chmod A0- test.dir
# ls -dv test.dir
drwxr-xr-x   2 root     root           2 May 20 15:09 test.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Ejemplo 8–3 Interacción de ACL con permisos en archivos ZFS

Estos ejemplos ilustran la interacción entre el establecimiento de ACL y el cambio de los permisos del archivo o el directorio.

En el ejemplo siguiente, en file.2 hay una ACL trivial:

# ls -v file.2
-rw-r--r--   1 root     root        3103 May 20 15:23 file.2
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

En el ejemplo siguiente, se retiran los permisos allow de everyone@.

# chmod A5- file.2
# ls -v file.2
-rw-r-----+  1 root     root        3103 May 20 15:23 file.2
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny

En esta salida, los permisos del archivo se restablecen de 644 a 640. Los permisos de lectura de everyone@ se suprimen de los permisos del archivo cuando se retiran los permisos de allow de ACL para everyone@.

En el ejemplo siguiente, la ACL se reemplaza con permisos de read_data/write_data para everyone@:

# chmod A=everyone@:read_data/write_data:allow file.3
# ls -v file.3
-rw-rw-rw-+  1 root     root        6986 May 20 15:25 file.3
     0:everyone@:read_data/write_data:allow

En esta salida, la sintaxis de chmod reemplaza la ACL con permisos de read_data/write_data:allow por permisos de lectura/escritura para owner (propietario), group (grupo) y everyone@ (cualquiera). En este modelo, everyone@ especifica acceso a cualquier grupo o usuario. Como no hay entrada de ACL de owner@ o group@ para anular los permisos de propietario y grupo, los permisos se establecen en 666.

En el ejemplo siguiente, la ACL se reemplaza por permisos de lectura para el usuario gozer:

# chmod A=user:gozer:read_data:allow file.3
# ls -v file.3
----------+  1 root     root        6986 May 20 15:25 file.3
     0:user:gozer:read_data:allow

En esta salida, los permisos de archivo se calculan como 000 porque no hay entradas de ACL para owner@, group@ ni everyone@, que representan los componentes de permisos habituales de un archivo. El propietario del archivo puede solventar esta situación restableciendo los permisos (y la ACL) de la forma siguiente:

# chmod 655 file.3
# ls -v file.3
-rw-r-xr-x+  1 root     root        6986 May 20 15:25 file.3
     0:user:gozer::deny
     1:user:gozer:read_data:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data:deny
     5:group@:read_data/execute:allow
     6:everyone@:write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
         /synchronize:allow

Ejemplo 8–4 Restauración de ACL triviales en archivos ZFS

Puede utilizar el comando chmod para eliminar todas las ACL no triviales de un archivo o un directorio, de modo que se restauren sus ACL triviales.

En el ejemplo siguiente, hay dos entradas de control de acceso no triviales en test5.dir:

# ls -dv test5.dir
drwxr-xr-x+  2 root     root           2 May 20 15:32 test5.dir
     0:user:lp:read_data:file_inherit:deny
     1:user:gozer:read_data:file_inherit:deny
     2:owner@::deny
     3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     4:group@:add_file/write_data/add_subdirectory/append_data:deny
     5:group@:list_directory/read_data/execute:allow
     6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

En el ejemplo siguiente, se han eliminado las ACL no triviales de los usuarios gozer y lp. La ACL restante contiene los seis valores predeterminados de owner@, group@ y everyone@.

# chmod A- test5.dir
# ls -dv test5.dir
drwxr-xr-x   2 root     root           2 May 20 15:32 test5.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Establecimiento de herencia de ACL en archivos ZFS en formato detallado

Puede especificar de qué modo se heredan ACL en archivos y directorios. De forma predeterminada, las ACL no se propagan. Si en un directorio se establece una ACL no trivial, no se heredará en ningún directorio posterior. Debe establecer la herencia de una ACL en un archivo o directorio.

Además, se proporcionan dos propiedades de ACL que se pueden establecer de forma global en sistemas de archivos: aclinherit y aclmode. De modo predeterminado, aclinherit se establece en restricted y aclmode se establece en groupmask.

Para obtener más información, consulte Herencia de ACL.

Ejemplo 8–5 Concesión de herencia de ACL predeterminada

De forma predeterminada, las ACL no se propagan en una estructura de directorios.

En el ejemplo siguiente, se aplica una entrada de control de acceso no trivial de read_data/write_data/execute para el usuario gozer en el directorio test.dir:

# chmod A+user:gozer:read_data/write_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 May 20 15:41 test.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Si se crea un subdirectorio de test.dir, no se propaga la entrada de control de acceso del usuario gozer. El usuario gozer sólo dispondrá de acceso al subdirectorio si se le conceden permisos como propietario del archivo, miembro del grupo o everyone@. Por ejemplo:

# mkdir test.dir/sub.dir
# ls -dv test.dir/sub.dir
drwxr-xr-x   2 root     root           2 May 20 15:42 test.dir/sub.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Ejemplo 8–6 Concesión de herencia de ACL en archivos y directorios

En los ejemplos siguientes se identifican las entradas de control de acceso de archivos y directorios que se aplican al establecerse el indicador file_inherit.

En este ejemplo, se agregan permisos de read_data/write_data en archivos del directorio test2.dir para el usuario gozer, de manera que disponga de acceso de lectura en cualquier archivo que se cree:

# chmod A+user:gozer:read_data/write_data:file_inherit:allow test2.dir
# ls -dv test2.dir
drwxr-xr-x+  2 root     root           2 May 20 15:50 test2.dir
     0:user:gozer:read_data/write_data:file_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

En el ejemplo siguiente, los permisos del usuario gozer se aplican en el archivo test2.dir/file.2 recién creado. La herencia de ACL concedida, read_data:file_inherit:allow, significa que el usuario gozer puede leer el contenido de cualquier archivo que se cree.

# touch test2.dir/file.2
# ls -v test2.dir/file.2
-rw-r--r--+  1 root     root           0 May 20 15:51 test2.dir/file.2
     0:user:gozer:write_data:deny
     1:user:gozer:read_data/write_data:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Puesto que la propiedad aclmode para este archivo tiene el valor predeterminado, groupmask, el usuario gozer no tiene el permiso write_data en file.2 porque no lo permite el permiso de grupo para el archivo.

Al usar el permiso inherit_only, que se concede si se establecen los indicadores file_inherit o dir_inherit, la ACL se propaga en la estructura de directorios. Así, al usuario gozer sólo se le conceden o deniegan permisos de everyone@ a menos que sea propietario del archivo o miembro del grupo propietario del archivo. Por ejemplo:

# mkdir test2.dir/subdir.2
# ls -dv test2.dir/subdir.2
drwxr-xr-x+  2 root     root           2 May 20 15:52 test2.dir/subdir.2
     0:user:gozer:list_directory/read_data/add_file/write_data:file_inherit
         /inherit_only:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

En los ejemplos siguientes se identifican las ACL de archivo y directorio que se aplican si se establecen los indicadores file_inherit y dir_inherit.

En este ejemplo, al usuario gozer se le conceden permisos de lectura, escritura y ejecución que se heredan para archivos y directorios recientemente creados:

# chmod A+user:gozer:read_data/write_data/execute:file_inherit/dir_inherit:allow 
test3.dir
# ls -dv test3.dir
drwxr-xr-x+  2 root     root           2 May 20 15:53 test3.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/dir_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

# touch test3.dir/file.3
# ls -v test3.dir/file.3
-rw-r--r--+  1 root     root           0 May 20 15:58 test3.dir/file.3
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

# mkdir test3.dir/subdir.1
# ls -dv test3.dir/subdir.1
drwxr-xr-x+  2 root     root           2 May 20 15:59 test3.dir/subdir.1
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/dir_inherit/inherit_only:allow
     1:user:gozer:add_file/write_data:deny
     2:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     3:owner@::deny
     4:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     5:group@:add_file/write_data/add_subdirectory/append_data:deny
     6:group@:list_directory/read_data/execute:allow
     7:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     8:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

En estos ejemplos, debido a que los permisos del directorio principal para group@ y everyone@ deniegan permisos de lectura y ejecución, al usuario gozer se le deniegan permisos de escritura y ejecución. El valor predeterminado de la propiedad aclinherit es restricted, lo cual significa que no se heredan los permisos write_data y execute.

En este ejemplo, al usuario gozer se le conceden permisos de lectura, escritura y ejecución que se heredan para archivos creados recientemente. Pero no se propagan por el resto del contenido del directorio.

# chmod A+user:gozer:read_data/write_data/execute:file_inherit/no_propagate:allow 
test4.dir
# ls -dv test4.dir
drwxr-xr-x+  2 root     root           2 May 20 16:02 test4.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/no_propagate:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Como puede verse en este ejemplo, si se crea un subdirectorio, los permisos read_data/write_data/execute del usuario gozer no se propagan al nuevo directorio sub4.dir:

mkdir test4.dir/sub4.dir
# ls -dv test4.dir/sub4.dir
drwxr-xr-x   2 root     root           2 May 20 16:03 test4.dir/sub4.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Como se observa en el ejemplo siguiente, los permisos read_data/write_data/execute del usuario gozer para archivos se propagan al archivo que acaba de crearse:

# touch test4.dir/file.4
# ls -v test4.dir/file.4
-rw-r--r--+  1 root     root           0 May 20 16:04 test4.dir/file.4
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Ejemplo 8–7 Herencia de ACL con la propiedad `aclmode` establecida como `passthrough`

Como muestra el siguiente ejemplo, cuando la propiedad aclmode del sistema de archivos tank/cindys se configura como passthrough , el usuario gozer hereda la ACL aplicada al directorio test4.dir para el archivo file.4 recién creado:

# zfs set aclmode=passthrough tank/cindys
# touch test4.dir/file.4
# ls -v test4.dir/file.4
-rw-r--r--+  1 root     root           0 May 20 16:08 test4.dir/file.4
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

En esta salida se observa que la ACL read_data/write_data/execute:allow:file_inherit/dir_inherit establecida en el directorio principal, test4.dir, se transfiere al usuario gozer.

Ejemplo 8–8 Herencia de ACL con la propiedad `aclmode` establecida como `discard`

Si la propiedad aclmode en un sistema de archivo se establece en discard, las ACL podrían descartarse si cambian los permisos en un directorio. Por ejemplo:

# zfs set aclmode=discard tank/cindys
# chmod A+user:gozer:read_data/write_data/execute:dir_inherit:allow test5.dir
# ls -dv test5.dir
drwxr-xr-x+  2 root     root           2 May 20 16:09 test5.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :dir_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Si, posteriormente, decide restringir los permisos de un directorio, se prescinde de la ACL no trivial. Por ejemplo:

# chmod 744 test5.dir
# ls -dv test5.dir
drwxr--r--   2 root     root           2 May 20 16:09 test5.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data/execute:deny
     3:group@:list_directory/read_data:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /execute/write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/read_attributes/read_acl
         /synchronize:allow

Ejemplo 8–9 Herencia de ACL con la propiedad `aclinherit` definida en `noallow`

En este ejemplo se establecen dos ACL no triviales con herencia de archivos. Una ACL concede el permiso read_data y la otra deniega el permiso read_data. Asimismo, el ejemplo muestra la manera de especificar dos entradas de control de acceso en el mismo comando chmod.

# zfs set aclinherit=noallow tank/cindys
# chmod A+user:gozer:read_data:file_inherit:deny,user:lp:read_data:file_inherit:allow 
test6.dir
# ls -dv test6.dir
drwxr-xr-x+  2 root     root           2 May 20 16:11 test6.dir
     0:user:gozer:read_data:file_inherit:deny
     1:user:lp:read_data:file_inherit:allow
     2:owner@::deny
     3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     4:group@:add_file/write_data/add_subdirectory/append_data:deny
     5:group@:list_directory/read_data/execute:allow
     6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Como muestra el ejemplo siguiente, al crear un archivo, se prescinde de la ACL que concede el permiso read_data.

# touch test6.dir/file.6
# ls -v test6.dir/file.6
-rw-r--r--   1 root     root           0 May 20 16:13 test6.dir/file.6
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Establecimiento y visualización de ACL en archivos ZFS en formato compacto

En archivos ZFS puede establecer y visualizar permisos en un formato compacto que utiliza 14 caracteres exclusivos para representar los permisos. Las letras que representan los permisos compactos se detallan en la Tabla 8–2 y la Tabla 8–3.

Puede visualizar listas de ACL en formato compacto para archivos y directorios mediante el comando ls -V. Por ejemplo:

# ls -V file.1
-rw-r--r--   1 root     root      206663 Jun 17 10:07 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Esta salida ACL compacta se describe de este modo:

owner@: Se deniegan al propietario permisos de ejecución en el archivo (x= execute).
owner@: El propietario puede leer y modificar el contenido del archivo ( rw=read_data/write_data, p= append_data). Asimismo, puede modificar atributos del archivo como indicaciones de hora, atributos extendidos y ACL (A=write_xattr, W=write_attributes y C=write_acl). Además, el propietario puede modificar la propiedad del archivo (o=write_owner).
group@: Se deniegan al grupo los permisos de modificación y ejecución del archivo (write_data, p=append_data y x=execute).
group@: Se conceden al grupo permisos de ejecución en el archivo (r= read_data).
everyone@: Se deniega a quien no sea propietario del archivo o miembro del grupo propietario el permiso de ejecución o modificación del contenido del archivo y de cualquiera de sus atributos (w= write_data, x=execute, p =append_data, A=write_xattr , W=write_attributes, C= write_acl y o=write_owner).
everyone@: Quien no sea propietario del archivo o miembro del grupo propietario del archivo y sus atributos (r= read_data, a=append_data, R=read_xattr, c=read_acl y s=synchronize). El permiso de acceso synchronize no está implementado en la actualidad.

El formato compacto de ACL presenta las ventajas siguientes respecto al formato detallado:

Los permisos se pueden especificar como argumentos posicionales en el comando chmod.
Los guiones (-), que no identifican permisos, se pueden eliminar. Sólo hace falta especificar las letras necesarias.
Los indicadores de permisos y de herencia se establecen de la misma manera.

Para obtener información sobre el uso del formato de ACL detallado, consulte Establecimiento y visualización de ACL en archivos ZFS en formato detallado.

Ejemplo 8–10 Establecimiento y visualización de las ACL en formato compacto

En el ejemplo siguiente, existe una ACL trivial en file.1:

# ls -V file.1
-rw-r--r--   1 root     root      206663 Jun 17 10:07 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

En el ejemplo siguiente, se agregan permisos read_data/execute para el usuario gozer en file.1:

# chmod A+user:gozer:rx:allow file.1
# ls -V file.1
-rw-r--r--+  1 root     root      206663 Jun 17 10:07 file.1
        user:gozer:r-x-----------:------:allow
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Una forma alternativa de agregar los mismos permisos para el usuario gozer consiste en insertar una ACL nueva en una posición determinada, por ejemplo 4. Así se desplazan hacia abajo las posiciones ya existentes entre la 4 y la 6. Por ejemplo:

# chmod A4+user:gozer:rx:allow file.1
# ls -V file.1
-rw-r--r--+  1 root     root      206663 Jun 17 10:16 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
        user:gozer:r-x-----------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

En el ejemplo siguiente, al usuario gozer se le conceden permisos de lectura, escritura y ejecución que se heredan para archivos y directorios recientemente creados.

# chmod A+user:gozer:rwx:fd:allow dir.2
# ls -dV dir.2
drwxr-xr-x+  2 root     root           2 Jun 17 10:19 dir.2
        user:gozer:rwx-----------:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:-w-p----------:------:deny
            group@:r-x-----------:------:allow
         everyone@:-w-p---A-W-Co-:------:deny
         everyone@:r-x---a-R-c--s:------:allow

También puede cortar y pegar indicadores de herencia y permisos de la salida de ls -V en el formato compacto de chmod. Por ejemplo, para duplicar los permisos e indicadores de herencia en el directorio dir.2 del usuario gozer para el usuario cindys en dir.2, copie y pegue los permisos y los indicadores de herencia (rwx-----------:fd----:allow) en el comando chmod como se indica a continuación:

# chmod A+user:cindys:rwx-----------:fd----:allow dir.2
# ls -dV dir.2
drwxr-xr-x+  2 root     root           2 Jun 17 10:19 dir.2
       user:cindys:rwx-----------:fd----:allow
        user:gozer:rwx-----------:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:-w-p----------:------:deny
            group@:r-x-----------:------:allow
         everyone@:-w-p---A-W-Co-:------:deny
         everyone@:r-x---a-R-c--s:------:allow

Ejemplo 8–11 Herencia de ACL con la propiedad `aclinherit` establecida en `passthrough`

Un sistema de archivos que tiene la propiedad aclinherit establecida en passthrough hereda todas las entradas ACL que se pueden heredar sin que se les apliquen modificaciones al heredarlas. Si la propiedad se establece en passthrough, los archivos se crean con permisos determinados por las entradas de control de acceso que se pueden heredar. Si no existen entradas de control de acceso que se puedan heredar y que afecten a los permisos, los permisos se configurarán de acuerdo con los solicitados desde la aplicación.

Los ejemplos siguientes utilizan sintaxis de ACL compacta para mostrar cómo heredar permisos estableciendo la propiedad aclinherit en passthrough.

En este ejemplo hay una ACL establecida en el directorio test1.dir para la forzar la herencia. La sintaxis crea una entrada ACL owner@, group@ y everyone@ para cada archivo recién creado. Los directorios que cree heredan una entrada ACL @owner, group@ y everyone@. Asimismo, los directorios heredan otras seis entradas de control de acceso que propagan las entradas de control de acceso a los directorios y archivos que se creen.

# zfs set aclinherit=passthrough tank/cindys
# pwd
/tank/cindys
# mkdir test1.dir

# chmod A=owner@:rwxpcCosRrWaAdD:fd:allow,group@:rwxp:fd:allow,everyone@::fd:allow 
test1.dir
# ls -Vd test1.dir
drwxrwx---+  2 root     root           2 Jun 17 10:37 test1.dir
            owner@:rwxpdDaARWcCos:fd----:allow
            group@:rwxp----------:fd----:allow
         everyone@:--------------:fd----:allow

En este ejemplo, un archivo recién creado hereda la ACL especificada para heredarse en los archivos recién creados.

# cd test1.dir
# touch file.1
# ls -V file.1
-rwxrwx---+  1 root     root           0 Jun 17 10:38 file.1
            owner@:rwxpdDaARWcCos:------:allow
            group@:rwxp----------:------:allow
         everyone@:--------------:------:allow

En este ejemplo, un directorio que se cree hereda tanto las entradas que controlan el acceso a este directorio como las entradas de control de acceso para la futura propagación a los elementos secundarios del directorio que se cree.

# mkdir subdir.1
# ls -dV subdir.1
drwxrwx---+  2 root     root           2 Jun 17 10:39 subdir.1
            owner@:rwxpdDaARWcCos:fdi---:allow
            owner@:rwxpdDaARWcCos:------:allow
            group@:rwxp----------:fdi---:allow
            group@:rwxp----------:------:allow
         everyone@:--------------:fdi---:allow
         everyone@:--------------:------:allow

Las entradas -di-- y f-i--- propagan la herencia y no se tienen en cuenta durante el control de acceso. En este ejemplo, se crea un archivo con una ACL trivial en otro directorio en el que no haya entradas de control de acceso heredadas.

# cd /tank/cindys
# mkdir test2.dir
# cd test2.dir
# touch file.2
# ls -V file.2
-rw-r--r--   1 root     root           0 Jun 17 10:40 file.2
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Ejemplo 8–12 Herencia de ACL con la propiedad `aclinherit` establecida en `passthrough-x`

Cuando la propiedad aclinherit está establecida en passthrough-x , los archivos se crean con el permiso de ejecución (x) para owner@, group@ o everyone@, pero sólo si el permiso de ejecución se establece en modo de creación de archivos y una ACE heredable que afecta al modo.

El siguiente ejemplo muestra cómo se heredan los permisos de ejecución estableciendo la propiedad aclinherit en passthrough-x.

# zfs set aclinherit=passthrough-x tank/cindys

La siguiente ACL se ha establecido en /tank/cindys/test1.dir para proporcionar herencia de ACL ejecutable para los archivos de owner@, group@ y everyone@.

# chmod A=owner@:rwxpcCosRrWaAdD:fd:allow,group@:rwxp:fd:allow,everyone@::fd:allow test1.dir
# ls -Vd test1.dir
drwxrwx---+  2 root     root           2 Jun 17 10:41 test1.dir
            owner@:rwxpdDaARWcCos:fd----:allow
            group@:rwxp----------:fd----:allow
         everyone@:--------------:fd----:allow

Un archivo (file1) se crea con permisos solicitados 0666. Los permisos resultantes son 0660. El permiso de ejecución no se ha heredado porque el modo de creación no lo solicitó.

# touch test1.dir/file1
# ls -V test1.dir/file1
-rw-rw----+  1 root     root           0 Jun 17 10:42 test1.dir/file1
            owner@:rw-pdDaARWcCos:------:allow
            group@:rw-p----------:------:allow
         everyone@:--------------:------:allow

A continuación, se generará un ejecutable llamado t mediante el compilador cc en el directorio testdir.

# cc -o t t.c
# ls -V t
-rwxrwx---+  1 root     root        7396 Jun 17 10:50 t
                 owner@:rwxpdDaARWcCos:------:allow
                 group@:rwxp----------:------:allow
              everyone@:--------------:------:allow

Los permisos resultantes son 0770 porque cc solicitó permisos 0777, que provocaron que el permiso de ejecución se heredara de las entradas owner@, group@ y everyone@.