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