Guía de administración de Oracle Solaris ZFS

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.