Modelo de ACL de Solaris

Las versiones anteriores de Solaris admitían una implementación de listas de control de acceso (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 interoperabilidad 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.

A continuación se exponen las diferencias principales del nuevo modelo de ACL:

Se basa en la especificación de NFSv4 y se parece a las ACL del tipo NT.
Proporciona un conjunto mucho más granular de privilegios de acceso. Para obtener más información, consulte la Tabla 7-2.
Se define y visualiza con los comandos chmod y ls, en lugar de los comandos setfacl y getfacl.
Aporta una semántica heredada mucho más rica para establecer la forma en que se aplican privilegios de acceso del directorio a los directorios, 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 de 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 hay definidos en dicha entrada.

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

Si emplea una utilidad que tiene en cuenta las ACL, por ejemplo 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 las 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 inferior 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 ACL de tipo POSIX, se convierten a ACL de tipo NFSv4.
Si intenta definir una ACL del 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 las ACL

Se proporcionan dos formatos básicos de ACL:

ACL trivial: contiene únicamente entradas las entradas tradicionales de UNIX user, group y owner.
ACL no trivial: contiene otras entradas además de owner, group y everyone, incluye conjuntos de indicadores heredados o las entradas están ordenadas de una manera no tradicional.

Sintaxis para definir ACL triviales

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 de ACL de la sintaxis de ACL triviales. Para obtener una descripción de tipos de entrada de ACL, consulte la Tabla 7-1.
user or group:ACL-entry-ID=username or groupname: Identifica el tipo de entrada de ACL de la sintaxis de ACL explícitas. El usuario y el grupo de ACL-entry-type deben contener también el ACL-entry-ID, username o groupname. Para obtener una descripción de tipos de entrada de ACL, consulte la Tabla 7-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 7-2.
inheritance-flags: Identifica una lista opcional de indicadores de herencia de ACL. Para obtener una descripción de los indicadores de herencia, consulte la Tabla 7-4.
deny | allow: Identifica si se conceden o deniegan los permisos de acceso.

En el siguiente ejemplo, no existe ningún valor de ID de entrada de ACL para owner@, group@ o everyone@.

group@:write_data/append_data/execute:deny

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

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

El 2 o el ID de índice de este ejemplo identifica la entrada de ACL de 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 el comando chmod de una forma similar a la siguiente:

chmod A3=user:venkman:read_acl:allow filename

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

Tabla 7-1 Tipos de entrada 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. Debe incluir el ID de entrada de ACL, que contiene un `username` o `userID`. Si el valor no es un ID de usuario numérico o `username` 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. Debe incluir el ID de entrada de ACL, que contiene un `groupname` o `groupID`. Si el valor no es un ID de grupo numérico o `groupname` válido, el tipo de entrada de ACL tampoco es válido.

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

Tabla 7-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`	Actualmente no se ha implementado.
`delete`	`d`	Permiso para suprimir un archivo. Para obtener más información sobre el comportamiento de permiso `delete` específico, consulte la Tabla 7-3.
`delete_child`	`D`	Permiso para suprimir un archivo o un directorio dentro de un directorio. Para obtener más información sobre el comportamiento de permiso `delete_child` específico, consulte la Tabla 7-3.
`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 del 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`	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 las horas asociadas 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 del 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`.

La siguiente tabla proporciona información adicional sobre los comportamientos de ACL delete y delete_child .

Tabla 7-3 Comportamientos de permiso de ACL delete y delete_child

Permisos de directorio principal	Permisos de objeto de destino
	ACL permite suprimir	ACL deniega suprimir	Permiso de supresión no especificado
ACL permite `delete_child`	Permitir	Permitir	Permitir
ACL deniega `delete_child`	Permitir	Denegar	Denegar
ACL permite solamente `write` y `execute`	Permitir	Permitir	Permitir
ACL deniega `write` y `execute`	Permitir	Denegar	Denegar

Conjuntos de LCA de ZFS

Las siguientes combinaciones de ACL se pueden aplicar en un conjunto de ACL en lugar de establecer permisos individuales por separado. Están disponibles los siguientes conjuntos de ACL.

Nombre de conjunto de ACL	Permisos de ACL incluidos
`full_set`	Todos los permisos
`modify_set`	Todos los permisos salvo `write_acl` y `write_owner`
`read_set`	`read_data`, `read_attributes`, `read_xattr` y `read_acl`
`write_set`	`write_data`, `append_data`, `write_attributes` y `write_xattr`

Estos conjuntos de ACL vienen predefinidos y no se pueden modificar.

Herencia de ACL

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

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

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

Tabla 7-4 Indicadores de herencia de ACL

Indicador de herencia	Indicador de herencia compacto	Descripción
`file_inherit`	`f`	La ACL sólo se hereda del directorio superior a los archivos del directorio.
`dir_inherit`	`d`	La ACL sólo se hereda del directorio superior 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/A	Ningún permiso concedido.
Actualmente, los siguientes indicadores se aplican solamente a un servidor o cliente de SMB.
`successful_access`	`S`	Indica si se debe iniciar una alarma o un registro de auditoría cuando un acceso es correcto. Este indicador se utiliza con tipos de ACE de auditoría o de alarma.
`failed_access`	`F`	Indica si se debe iniciar una alarma o un registro de auditoría cuando un acceso falla. Este indicador se utiliza con tipos de ACE de auditoría o de alarma.
`inherited`	`I`	Indica que se ha heredado una ACE.

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

El sistema de archivos ZFS incluye las siguientes propiedades de ACL para determinar el comportamiento específico de herencia de ACL e interacción de ACL con operaciones chmod.

aclinherit: determina el comportamiento de herencia de ACL. Entre los valores se incluyen los siguientes:
- discard: en los objetos nuevos, si se crea un archivo o directorio, no se heredan entradas de LCA. La ACL del archivo o directorio es igual al modo de permiso del archivo o directorio.
- noallow: en los objetos nuevos, sólo se heredan las entradas de LCA 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 un modo 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 al modo, el modo se configurará de acuerdo con el modo solicitado desde la aplicación.
- Passthrough-x : tiene la misma semántica que passthrough, excepto que cuando passthrough-x está activada, los archivos se crean con el permiso de ejecución (x), pero sólo si el permiso de ejecución se ha establecido en el modo de creación de archivos y en un ACE heredable que afecta al modo.
El modo predeterminado para aclinherit es restricted.
aclmode: modifica el comportamiento de ACL cuando un archivo se crea por primera vez o controla cómo se modifica una ACL durante una operación chmod. Puede tener los valores siguientes:
- discard: un sistema de archivos con una propiedad aclmode de discard suprime todas las entradas de ACL que no representan el modo del archivo. Éste es el valor predeterminado.
- mask: un sistema de archivos con una propiedad aclmode de mask reduce los permisos de usuario o de grupo. Se reducen los permisos para que no superen los bits de permisos de grupo, a menos que se trate de una entrada de usuario cuyo UID sea igual al del propietario del archivo o directorio. Así, los permisos de ACL se reducen para que no superen los bits de permisos del propietario. El valor de máscara también conserva la ACL cuando cambian los modos, siempre que no se haya realizado una operación de conjunto de ACL explícita.
- passthrough: un sistema de archivos con una propiedad aclmode de passthrough indica que no se realizaron más cambios en la ACL aparte de generar las entradas necesarias de ACL para representar el nuevo modo del archivo o del directorio.
discard es el modo predeterminado de la propiedad aclmode.

Para obtener más información sobre el uso de la propiedad aclmode, consulte el Ejemplo 7-14.

Omitir Vínculos de navegación
Salir de la Vista de impresión
	Administración de Oracle Solaris 11.1: sistemas de archivos ZFS Oracle Solaris 11.1 Information Library (Español)