Omitir V�nculos de navegaci�n | |
Salir de la Vista de impresi�n | |
![]() |
Guía de administración de Oracle Solaris ZFS |
1. Sistema de archivos ZFS de Oracle Solaris (introducción)
2. Procedimientos iniciales con Oracle Solaris ZFS
3. Oracle Solaris ZFS y sistemas de archivos tradicionales
4. Administración de agrupaciones de almacenamiento de Oracle Solaris ZFS
5. Instalación e inicio de un sistema de archivos raíz ZFS Oracle Solaris
6. Administrar sistemas de archivos ZFS de Oracle Solaris
7. Uso de clones e instantáneas de Oracle Solaris ZFS
8. Uso de listas de control de acceso y atributos para proteger archivos Oracle Solaris ZFS
Establecimiento de las ACL en archivos ZFS
Establecimiento y visualización de ACL en archivos ZFS en formato detallado
Establecimiento de herencia de ACL en archivos ZFS en formato detallado
Establecimiento y visualización de ACL en archivos ZFS en formato compacto
9. Administración delegada de ZFS Oracle Solaris
10. Temas avanzados de Oracle Solaris ZFS
11. Recuperación de agrupaciones y solución de problemas de Oracle Solaris ZFS
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.
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
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.
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.
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.
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.
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
|
En la tabla siguiente se describen los privilegios de acceso de ACL.
Tabla 8-2 Privilegios de acceso 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
|
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.
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.