Nuevo 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 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.

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 8-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:

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 8-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 debe contener también el ACL-entry-ID, username o groupname. Para obtener una descripción de tipos de entrada de 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 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 de ACL porque en la ACL se incluye un usuario específico (tipo de entrada de 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

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 entreadas 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 8-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 `nombre_usuario` o `ID_usuario`. Si el valor no es un ID de usuario numérico o `nombre_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. Debe incluir el ID de entrada de ACL, que contiene un `nombre_grupo` o `ID_grupo`. Si el valor no es un ID de grupo numérico o `nombre_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	e	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	E	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 del archivo.
read_xattr	S	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	e	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 arbitratrio.
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`.

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 bits de permiso en el directorio superior.

De forma predeterminada, las ACL 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 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 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/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.

Propiedad de ACL (`aclinherit`)

El sistema de archivos ZFS incluye la propiedad aclinherit para determinar el comportamiento de la 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 ACL. 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 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 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á habilitada, 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.

Omitir V�nculos de navegaci�n
Salir de la Vista de impresi�n
	Guía de administración de Oracle Solaris ZFS