Guia de administração do ZFS Oracle Solaris

Capítulo 8 Utilizando ACLs para proteger arquivos ZFS do Oracle Solaris

Este capítulo fornece informações sobre a utilização das listas de controle de acesso (ACLs) para proteger os arquivos do ZFS. As ACLs fornecem permissões mais granulares que as permissões do UNIX padrão.

Este capítulo traz as seguintes seções:

Novo modelo de ACL do Solaris

As versões anteriores do Solaris OS ofereciam suporte a uma implementação de ACL com base principalmente na especificação da ACL do rascunho POSIX. As ACLs baseadas no esquema POSIX são usadas para proteger arquivos UFS e são traduzidas por versões do NFS antes do NFSv4

Com a introdução do NFSv4, um novo modelo de ACL oferece suporte total à interoperabilidade que o NFSv4 oferece entre clientes e não-clientes UNIX. A nova implementação de ACL, conforme definida na especificação NFSv4, proporciona semânticas muito mais ricas baseadas nas ACLs de estilo NT.

As principais diferenças do novo modelo de ACL são as seguintes:

O novo modelo de ACL tem base na especificação NSFv4 e é similar às ACLs de estilo NT.
O novo modelo fornece um conjunto muito mais granular de privilégios de acesso. Para obter mais informações, consulte a Tabela 8–2.
ACLs são definidas e exibidas com os comandos chmod e ls em vez dos comandos setfacl e getfacl .
O novo modelo oferece semânticas de herança mais ricas para designar como privilégios de acesso são aplicados de um diretório para subdiretórios, e assim por diante. Para obter mais informações, consulte Herança da ACL.

Ambos os modelos de ACL proporcionam controles de acesso mais granulares que os disponíveis nas permissões de arquivos padrão. Assim como as ACLs de esquema POSIX, as novas ACLs compõem-se de várias entradas de controle de acesso (ACEs).

As ACLs com base no rascunho POSIX utilizam uma única entrada para definir quais permissões são aceitas e quais permissões são negadas. O novo modelo de ACL apresenta dois tipos de ACEs que afetam a verificação de acesso: ALLOW e DENY. Não é possível deduzir, a partir de qualquer ACE que defina um conjunto de permissões, se as permissões definidas nesta ACE são permitidas ou negadas.

A tradução entre ACLs do NFSv4 e de rascunho POSIX é a seguinte:

Se utilizar utilitários com ACL, como os comandos cp, mv, tar, cpio ou rcp para transferir arquivos UFS com ACLs para um sistema de arquivos do ZFS, as ACLs de rascunho POSIX são traduzidas para as ACLs do NFSv4 equivalentes.
Algumas ACLs do NFSv4 são traduzidas para ACLs de rascunho POSIX. Se uma ACL do NFSv4 não for traduzida para uma ACL de rascunho POSIX, será exibida a seguinte mensagem:
# cp -p filea /var/tmp cp: failed to set acl entries on /var/tmp/filea
Se criar um arquivo UFS tar ou cpio com a opção de preservar ACL (tar -p ou cpio -P) em um sistema que executa uma versão atual do Solaris, você perderá as ACLs quando o arquivo for extraído para um sistema que executa uma versão anterior do Solaris.

Todos os arquivos são extraídos com os modos de arquivo corretos, mas as entradas ACL são ignoradas.
Você pode usar o comando ufsrestore para restaurar os dados dentro de um sistema de arquivos ZFS. Se os dados originais incluírem ACLs de rascunho POSIX, elas são traduzidas como ACLs NFSv4.
Se tentar definir uma ACL do NFSv4 em um arquivo UFS, será exibida uma mensagem semelhante à seguinte:
chmod: ERROR: ACL type's are different

Se tentar definir uma ACL de rascunho POSIX em um arquivo ZFS, será exibida uma mensagem semelhante à seguinte:

# getfacl filea
File system doesn't support aclent_t style ACL's.
See acl(5) for more information on Solaris ACL support.

Para obter mais informações sobre outras limitações com ACLs e produtos de backup, consulte Salvando dados do ZFS com outros produtos de backup.

Descrições de sintaxe para definição de ACLs

Seguem dois formatos básicos de ACL:

Sintaxe para definição de ACLs comuns

Uma ACL é comum visto que representa somente as entradas owner/group/other tradicionais do UNIX.

chmod [options] A[index]{+|=}owner@ |group@ |everyone@: access-permissions/...[:inheritance-flags]: deny | allow file

chmod [options] A-owner@, group@, everyone@:access-permissions /...[:inheritance-flags]:deny | allow file ...

chmod [options] A[index]- arquivo

Sintaxe para a configuração de ACLs incomuns

chmod [options] A[index]{+|=}user|group:name:access-permissions /...[:inheritance-flags]:deny | allow file

chmod [options] A-user|group:name:access-permissions /...[:inheritance-flags]:deny | allow file ...

chmod [options] A[index]- arquivo

owner@, group@, everyone@: Identifica o tipo de entrada ACL da sintaxe da ACL comum. Para uma descrição dos tipos de entrada da ACL, consulte a Tabela 8–1.
usuário ou grupo: ACL-entry-ID=username or groupname: Identifica o tipo de entrada ACL da sintaxe de ACL explícita. O usuário e grupo com tipo de entrada ACL devem conter também a ID da entrada ACL, nome do usuário ou nome do grupo. Para uma descrição dos tipos de entrada da ACL, consulte a Tabela 8–1.
access-permissions/.../: Identifica as permissões de acesso que são aceitas ou negadas. Para obter uma descrição dos privilégios de acesso da ACL, consulte a Tabela 8–2.
inheritance-flags: Identifica uma lista opcional de sinalizadores de herança da ACL. Para obter uma descrição dos sinalizadores de herança da ACL, consulte a Tabela 8–3.
deny | allow: Identifica se as permissões de acesso são aceitas ou negadas.

No exemplo abaixo, o valor do ID da entrada ACL não é relevante:

group@:write_data/append_data/execute:deny

O exemplo abaixo inclui um ID da entrada ACL porque um usuário específico (tipo da entrada ACL) está incluído na ACL.

0:user:gozer:list_directory/read_data/execute:allow

Quando uma entrada ACL é exibida, ela se parece ao ilustrado abaixo:

2:group@:write_data/append_data/execute:deny

Neste exemplo, o 2 ou a designação da index-ID identifica a entrada ACL na ACL maior, que pode ter várias entradas para proprietário, UIDs específicos, grupo e todos. Você pode especificar o ID de índice com o comando chmod para identificar que parte da ACL quer modificar. É possível identificar, por exemplo, a ID de índice 3 como A3 na sintaxe de comando chmod, semelhante ao seguinte:

chmod A3=user:venkman:read_acl:allow filename

Na tabela abaixo encontram-se as descrições dos tipos de entrada ACL, que são as representações da ACL de proprietário, grupo e outros.

Tabela 8–1 Tipos de entrada ACL


Tipo de entrada ACL	Descrição
`owner@`	Especifica o acesso concedido ao proprietário do objeto.
`group@`	Especifica o acesso concedido ao grupo proprietário do objeto.
`everyone@`	Especifica o acesso permitido a todos os usuários ou grupos que não correspondam com nenhuma outra entrada ACL.
`user`	Com um nome de usuário, especifica o acesso concedido a um usuário adicional do objeto. Esta entrada deve incluir a ID da entrada ACL, que contém um `nome de usuário` ou uma `ID de usuário`. Se o valor não for um UID numérico ou `nome de usuário` válidos, o tipo de entrada ACL é inválido.
`group`	Com um nome de grupo, especifica acesso concedido a um grupo adicional do objeto. Esta entrada deve incluir a ID da entrada ACL, que contém um `nome de grupo` ou uma `ID de grupo`. Se o valor não for um GID numérico ou `nome de grupo` válidos, o tipo de entrada ACL é inválido.

Os privilégios de acesso da ACL estão descritos na tabela abaixo.

Tabela 8–2 Privilégios de acesso da ACL


Privilégio de acesso	Privilégio de acesso compacto	Descrição
`add_file`	`w`	Permissão para adicionar um novo arquivo a um diretório.
`add_subdirectory`	`p`	Em um diretório, permissão para criar um subdiretório.
`append_data`	`p`	Espaço reservado. Ainda não implementado.
`delete`	`d`	Permissão para excluir um arquivo.
`delete_child`	`D`	Permissão para excluir um arquivo ou um diretório dentro de um diretório.
`execute`	`x`	Permissão para executar um arquivo ou pesquisar o conteúdo de um diretório.
`list_directory`	`a`	Permissão para listar o conteúdo de um diretório.
`read_acl`	`c`	Permissão para ler a ACL (`ls`).
`read_attributes`	`a`	Permissão para ler os atributos básicos (não-ACLs) de um arquivo. Considere os atributos básicos como sendo os atributos do nível stat. Ao permitir este bit de máscara de acesso, a entidade pode executar `ls`(1) e `stat`(2).
`read_data`	`a`	Permissão para ler o conteúdo de um arquivo.
`read_xattr`	`A`	Permissão para ler os atributos estendidos de um arquivo ou efetuar uma consulta no diretório dos atributos estendidos do arquivo.
`synchronize`	`s`	Espaço reservado. Ainda não implementado.
`write_xattr`	`W`	Permissão para criar atributos estendidos ou gravar no diretório de atributos estendidos. A concessão de permissões a um usuário indica que o usuário pode criar um diretório de atributo estendido para um arquivo. As permissões do arquivo do atributo controlam o acesso do usuário ao atributo.
`write_data`	`w`	Permissão para modificar ou substituir o conteúdo de um arquivo.
`write_attributes`	`m`	Permissão para alterar os registros de data associados a um arquivo ou diretório para um valor arbitrário.
`write_acl`	`C`	Permissão para gravar a ACL ou modificar a ACL através do comando `chmod`.
`write_owner`	`o`	Permissão para alterar o proprietário ou o grupo do arquivo. Ou, a habilidade para executar os comandos `chown` ou `chgrp` no arquivo. Permissão para tomar a propriedade de um arquivo ou permissão para alterar a propriedade do grupo do arquivo para um grupo do qual o usuário é membro. Se quiser alterar a propriedade do grupo ou arquivo para um usuário ou grupo arbitrário, o privilégio `PRIV_FILE_CHOWN` é exigido.

Herança da ACL

O objetivo de utilizar a herança da ACL é que um arquivo ou diretório recém-criado pode herdar as ACLs que pretendem herdar, mas levando em consideração as permissões existentes no diretório pai.

Por padrão, as ACLs não são propagadas. Se definir uma ACL não-comum em um diretório, ela não será herdada por nenhum diretório subsequente. Você deve especificar a herança de uma ACL em um arquivo ou diretório.

Os sinalizadores de herança opcionais estão descritos na seguinte tabela.

Tabela 8–3 Sinalizadores de herança da ACL


Sinalizador de herança	Sinalizador de herança compacto	Descrição
`file_inherit`	`f`	Herda a ACL do diretório pai, mas se aplica apenas aos arquivos do diretório.
`dir_inherit`	`d`	Herda a ACL do diretório pai, mas se aplica apenas aos subdiretórios do diretório.
`inherit_only`	`i`	Herda a ACL do diretório pai, mas se aplica somente aos arquivos e subdiretórios recém-criados e não ao próprio diretório. Este sinalizador requer o sinalizador `file_inherit`, o sinalizador `dir_inherit`, ou ambos, para indicar o que herdar.
`no_propagate`	`n`	Herda somente a ACL do diretório pai até o conteúdo do primeiro nível do diretório, não herda o conteúdo do segundo nível ou dos níveis subseqüentes. Este sinalizador requer o sinalizador `file_inherit`, o sinalizador `dir_inherit`, ou ambos, para indicar o que herdar.
`-`	N/D	Nenhuma permissão concedida.

Além disso, é possível definir a política de herança da ACL padrão no sistema de arquivos para que seja mais rigorosa ou menos rigorosa utilizando a propriedade aclinherit do sistema de arquivos. Para obter mais informações, consulte a próxima seção.

Propriedades da ACL

O sistema de arquivos do ZFS possui duas propriedade relacionados às ACLs:

aclinherit – Esta propriedade determina o comportamento da herança da ACL. Os valores são os seguintes:
- discard – Para novos objetos, nenhuma entrada ACL é herdada quando um arquivo ou diretório é criado. A ACL no novo arquivo ou diretório é igual às permissões do arquivo ou diretório.
- noallow – Para novos objetos, somente as entradas ACLs herdáveis com um tipo de acesso deny são herdadas.
- restricted – Para novos objetos, as permissões write_owner e write_acl são removidas quando uma entrada ACL é herdada.
- passthrough: quando o valor da propriedade estiver definido como passthrough, os arquivos são criados com permissões determinadas pelas ACEs herdáveis. Se não existirem ACEs herdáveis que afetem as permissões, então as permissões serão definidas de acordo com as permissões solicitadas do aplicativo.
- passthrough-x : este valor de propriedade possui a mesma semântica de passthrough, exceto que, quando passthrough-x está ativado, os arquivos são criados com a permissão de execução (x), mas somente se a permissão de execução estiver definida no modo de criação de arquivo e em uma ACE de herança que afeta o modo.
O valor padrão da propriedade aclinherit é restricted.
aclmode: esta propriedade modifica o comportamento da ACL quando um arquivo é inicialmente criado ou sempre que as permissões de um arquivo ou diretório forem modificadas pelo comando chmod . Os valores são os seguintes:
- discard – Todas as entradas ACLs são removidas, exceto as entradas necessárias para definir o modo do arquivo ou diretório.
- groupmask: as permissões ACL de usuário ou grupo são reduzidas para que não sejam maiores que as permissões de grupo, a menos que seja uma entrada de usuário com o mesmo UID que o proprietário do arquivo ou diretório. Assim, as permissões de ACL são reduzidas para que não sejam maiores que as permissões do proprietário.
- passthrough – Durante uma operação chmod, as ACEs diferentes de owner@, group@ ou everyone@ não são modificadas de nenhuma forma. As ACEs com owner@, group@ ou everyone@ são desativadas para definir o modo de arquivo conforme solicitado pela operação chmod.
O valor padrão da propriedade aclmode é groupmask .

Definindo ACLs em arquivos ZFS

Por serem implementadas com o ZFS, as ACLs são compostas por entradas ACLs. O ZFS oferece um modelo de ACL puro, no qual todos os arquivos têm uma ACL. Normalmente, a ACL é comum porque representa somente entradas UNIX owner/group/other tradicionais.

Se alterar as permissões do arquivo, a ACL do arquivo será atualizada de acordo. Além disso, se remover uma ACL não-comum que dá ao usuário acesso ao arquivo ou diretório, tal usuário poderia continuar tendo acesso ao arquivo ou diretório devido aos bits de permissão do arquivo ou diretório que permitem acesso para um grupo ou para todos. Todos as decisões de controles de acesso são controladas pelas permissões representadas em uma ACL do arquivo ou diretório.

As principais regras de acesso de ACL em um arquivo do ZFS são as seguintes:

O ZFS processa as entradas ACLs com o objetivo de listá-las na ACL, de cima para baixo.
São processadas somente as entradas ACLs que têm “quem” corresponda ao solicitante do acesso.
Depois que a permissão allow foi concedida, ela não pode ser negada por uma entrada ACL deny subsequente no mesmo conjunto de permissões da ACL.
A permissão write_acl é concedida incondicionalmente ao proprietário de um arquivo, mesmo se a permissão for explicitamente negada. Caso contrário, todas as permissões não especificadas são negadas.

No caso de permissões deny, ou quando falta um acesso de permissão, o subsistema de privilégios determina qual solicitação de acesso é concedida ao proprietário do arquivo ou ao superusuário. Este mecanismo evita que os proprietários de arquivos sejam bloqueados a seus arquivos e ativa o superusuário para que modifique os arquivos para recuperação.

Se definir uma ACL não-comum em um diretório, os filhos do diretório não herdarão a ACL automaticamente. Se definir uma ACL não-comum e quiser que ela seja herdada pelos filhos do diretório, você terá que utilizar os sinalizadores de herança da ACL. Para obter mais informações, consulte a Tabela 8–3 e Definindo a herança da ACL em arquivos ZFS no formato verboso.

Quando um novo arquivo é criado e dependendo do valor de umask, um padrão de ACL comum, semelhante ao ilustrado abaixo, é aplicado:

$ ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 14:09 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Observe que cada categoria de usuário (owner@, group@, everyone@) possui duas entradas de ACL neste exemplo. Uma entrada para permissões deny e uma entrada para permissões allow.

A seguir, uma descrição dessa ACL do arquivo:

0:owner@: O proprietário não tem permissões de execução para o arquivo (execute:deny ).
1:owner@: O proprietário pode ler e modificar o conteúdo do arquivo ( read_data/write_data/append_data). O proprietário também pode modificar os atributos do arquivo, tais como registros de data, atributos estendidos e ACLs (write_xattr/write_attributes /write_acl). Além disso, o proprietário pode modificar a propriedade do arquivo (write_owner:allow).
2:group@: O grupo não tem permissões para modificar e executar no arquivo (write_data/append_data/execute:deny).
3:group@: O grupo tem permissões de leitura para o arquivo (read_data:allow ).
4:everyone@: Todos aqueles que não são proprietários de arquivos ou membros de um grupo de proprietários do arquivo não terão permissão para executar ou modificar o conteúdo de arquivos e nem para modificar os atributos do arquivo (write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny).
5:everyone@: Todos aqueles que não são proprietários de arquivos ou membros de um grupo de proprietários do arquivo possuem permissões no arquivo e em seus atributos (read_data/read_xattr/read_attributes/read_acl/synchronize:allow ). A permissão de acesso synchronize não está implementada atualmente.

Quando um novo diretório é criado e dependendo do valor de umask, uma ACL de diretório padrão, semelhante à ilustrada a seguir, é aplicada:

$ ls -dv dir.1
drwxr-xr-x   2 root     root           2 May 20 14:11 dir.1
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Segue uma descrição do diretório de ACL:

0:owner@: A lista deny do proprietário está vazia para o diretório (::deny).
1:owner@: O proprietário pode ler e modificar o conteúdo do diretório (list_directory/read_data/add_file/write_data//add_subdirectory/append_data ), pesquisa o conteúdo (execute) e modifica os atributos do arquivo, tais como registros de data, atributos estendidos e ACLs ( write_xattr/write_attributes/write_acl). Além disso, o proprietário pode modificar a propriedade do diretório (write_owner:allow).
2:group@: O grupo não pode adicionar ou modificar o conteúdo do diretório ( add_file/write_data/add_subdirectory/append_data:deny).
3:group@: O grupo pode listar e ler o conteúdo do diretório. Além disso, o grupo tem permissão para executar pesquisas no conteúdo do diretório (list_directory/read_data/execute:allow ).
4:everyone@: Todos aqueles que não são proprietários de arquivos ou membros de um grupo de proprietários do arquivo não terão permissão para adicionar ou modificar o conteúdo do diretório (add_file/write_data/add_subdirectory/append_data). Além disso, a permissão para modificar qualquer um dos atributos do diretório é negada (write_xattr/write_attributes/write_acl/write_owner:deny).
5:everyone@: Todos aqueles que não são proprietários de arquivos ou membros de um grupo de proprietários do arquivo terão permissão de leitura e execução no conteúdo e nos atributos do diretório (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow ). A permissão de acesso synchronize não está implementada atualmente.

Definindo e exibindo ACLs em arquivos ZFS no formato verboso

O comando chmod pode ser usado para modificar as ACLs em arquivos ZFS. A sintaxe de chmod abaixo para a modificação de ACLs usa acl-specification para identificar o formato da ACL. Para obter uma descrição de acl-specification, consulte Descrições de sintaxe para definição de ACLs.

Adicionando entradas ACLs
- Adicionando uma entrada ACL de um usuário
  % chmod A+acl-specification filename
- Adicionando uma entrada ACL por ID de índice
  % chmod Aindex-ID+acl-specification filename
  Esta sintaxe insere a nova entrada ACL no local do ID de índice especificado.

Substituindo uma entrada ACL

% chmod A=acl-specification filename

% chmod Aindex-ID=acl-specification filename

Removendo entradas ACLs
- Removendo uma entrada ACL por ID de índice
  % chmod Aindex-ID- filename
- Removendo uma entrada ACL por usuário
  % chmod A-acl-specification filename
- Removendo todas as ACEs não-comuns de um arquivo
  % chmod A- filename

As informações detalhadas da ACL são exibidas com o comando ls - v. Por exemplo:

# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 14:09 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Para obter mais informações sobre o uso do formato compacto da ACL, consulte Definindo e exibindo ACLs em arquivos ZFS no formato compacto.

Exemplo 8–1 Modificando ACLs comuns em arquivos ZFS

Esta seção oferece exemplos de configuração e exibição de ACLs comuns.

No exemplo abaixo, existe uma ACL comum no file.1:

# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

No exemplo abaixo, as permissões write_data são concedidas a group@:

# chmod A2=group@:append_data/execute:deny file.1
# chmod A3=group@:read_data/write_data:allow file.1
# ls -v file.1
-rw-rw-r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:append_data/execute:deny
     3:group@:read_data/write_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

No exemplo abaixo, as permissões no file.1 são redefinidas como 644.

# chmod 644 file.1
# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Exemplo 8–2 Definindo ACLs não-comuns em arquivos ZFS

Esta seção oferece exemplos de definições e exibições de ACLs não-comuns.

No exemplo a seguir, as permissões read_data/execute são adicionadas ao usuário gozer no diretório test.dir:

# chmod A+user:gozer:read_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 May 20 15:09 test.dir
     0:user:gozer:list_directory/read_data/execute:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

No exemplo abaixo, as permissões read_data/execute são removidas do usuário gozer:

# chmod A0- test.dir
# ls -dv test.dir
drwxr-xr-x   2 root     root           2 May 20 15:09 test.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Exemplo 8–3 A interação da ACL com permissões em arquivos ZFS

Estes exemplos ilustram a interação entre definir ACLs e alterar as permissões do arquivo ou diretório.

No exemplo abaixo, existe uma ACL comum em file.2:

# ls -v file.2
-rw-r--r--   1 root     root        3103 May 20 15:23 file.2
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

No exemplo a seguir, as permissões allow da ACL são removidas de everyone@:

# chmod A5- file.2
# ls -v file.2
-rw-r-----+  1 root     root        3103 May 20 15:23 file.2
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny

Nesta saída, as permissões do arquivo são redefinidos de 644 para 640. As permissões de leitura para everyone@ foram removidas com sucesso das permissões do arquivo quando as permissões allow da ACL foram removidas de everyone@.

No exemplo abaixo, a ACL existente é substituída pelas permissões read_data/write_data em everyone@:

# chmod A=everyone@:read_data/write_data:allow file.3
# ls -v file.3
-rw-rw-rw-+  1 root     root        6986 May 20 15:25 file.3
     0:everyone@:read_data/write_data:allow

Nessa saída, a sintaxe chmod substitui com sucesso a ACL existente pelas permissões read_data/write_data:allow para permitir leitura/gravação em owner, group e everyone@ . Nesse modelo, everyone@ especifica para qualquer usuário ou grupo. Visto que não existe nenhuma entrada ACL de owner@ ou de group@ para substituir as permissões para proprietário e grupo, as permissões são definidas como 666.

No exemplo abaixo, a ACL existente é substituída pelas permissões de leitura no usuário gozer:

# chmod A=user:gozer:read_data:allow file.3
# ls -v file.3
----------+  1 root     root        6986 May 20 15:25 file.3
     0:user:gozer:read_data:allow

Nessa saída, as permissões do arquivo são calculadas para que sejam 000 porque não existe nenhuma entrada ACL em owner@, group@ ou everyone@, que representam os componentes de permissões tradicionais de um arquivo. O proprietário do arquivo pode solucionar esse problema redefinindo as permissões (e a ACL) da seguinte forma:

# chmod 655 file.3
# ls -v file.3
-rw-r-xr-x+  1 root     root        6986 May 20 15:25 file.3
     0:user:gozer::deny
     1:user:gozer:read_data:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data:deny
     5:group@:read_data/execute:allow
     6:everyone@:write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
         /synchronize:allow

Exemplo 8–4 Restaurando ACLs comuns em arquivos ZFS

É possível utilizar o comando chmod para remover todas as ACLs não-comuns em um arquivo ou diretório e, assim, restaurar as ACLs comuns no arquivo ou diretório.

No exemplo abaixo, existem duas ACEs não-comuns em test5.dir:

# ls -dv test5.dir
drwxr-xr-x+  2 root     root           2 May 20 15:32 test5.dir
     0:user:lp:read_data:file_inherit:deny
     1:user:gozer:read_data:file_inherit:deny
     2:owner@::deny
     3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     4:group@:add_file/write_data/add_subdirectory/append_data:deny
     5:group@:list_directory/read_data/execute:allow
     6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

No exemplo abaixo, as ACLs não-comuns de usuários gozer e lp são removidas. A ACL restante contém seis valores padrão em owner@, group@ e everyone@.

# chmod A- test5.dir
# ls -dv test5.dir
drwxr-xr-x   2 root     root           2 May 20 15:32 test5.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Definindo a herança da ACL em arquivos ZFS no formato verboso

É possível especificar se e como as ACLs são herdadas nos arquivos do diretório. Por padrão, as ACLs não são propagadas. Se uma ACL não-comum for definida em um diretório, a ACL não será herdada por nenhum diretório subseqüente. É possível especificar a herança de uma ACL em um arquivo ou diretório.

Além disso, são oferecidas duas propriedades de ACL que podem ser definidas globalmente em sistemas de arquivos: aclinherit e aclmode. Por padrão, aclinherit é definida como restricted e aclmode é definida como groupmask .

Para obter mais informações, consulte Herança da ACL.

Exemplo 8–5 Concedendo herança de ACL padrão

Por padrão, as ACLs não se propagam pela estrutura do diretório.

No exemplo seguinte, uma ACE não-comum de read_data/write_data/execute é aplicada para o usuário gozer no diretório test.dir:

# chmod A+user:gozer:read_data/write_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 May 20 15:41 test.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Se for criado um subdiretório test.dir, a ACE não se propaga para o usuário gozer. O usuário gozer teria acesso ao subdiretório somente se as permissões no subdiretório lhe permitissem acessar como proprietário de arquivo, membro de grupo ou everyone@. Por exemplo:

# mkdir test.dir/sub.dir
# ls -dv test.dir/sub.dir
drwxr-xr-x   2 root     root           2 May 20 15:42 test.dir/sub.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Exemplo 8–6 Permitindo herança de ACL em arquivos e diretórios

Os exemplos a seguir identificam as ACEs do arquivo e do diretório que são aplicadas quando o sinalizador file_inherit está definido.

Neste exemplo, as permissões read_data/write_data são adicionadas para arquivos do diretório test.dir do usuário gozer, para que ele tenha acesso de leitura a quaisquer arquivos recém-criados:

# chmod A+user:gozer:read_data/write_data:file_inherit:allow test2.dir
# ls -dv test2.dir
drwxr-xr-x+  2 root     root           2 May 20 15:50 test2.dir
     0:user:gozer:read_data/write_data:file_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Neste exemplo, as permissões do usuário gozer são aplicadas no arquivo test2.dir/file.2 recém-criado. A herança de ACL fornecida, read_data:file_inherit:allow, indica que o usuário gozer pode ler o conteúdo de todos os arquivos recém-criados.

# touch test2.dir/file.2
# ls -v test2.dir/file.2
-rw-r--r--+  1 root     root           0 May 20 15:51 test2.dir/file.2
     0:user:gozer:write_data:deny
     1:user:gozer:read_data/write_data:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Pelo fato da propriedade aclmode para este arquivo estar definida com o valor padrão (groupmask), o usuário gozer não tem a permissão write_data no file.2 porque a permissão de grupo do arquivo não lhe permite.

Ao utilizar a permissão inherit_only, aplicada quando os sinalizadores file_inherit ou dir_inherit são definidos, é utilizada para propagar a ACL pela estrutura do diretório. Como tal, o usuário gozer tem permissão concedida ou negada apenas a partir das permissões de everyone@, a não ser que ele seja o proprietário do arquivo ou um membro do grupo ao qual o arquivo pertence. Por exemplo:

# mkdir test2.dir/subdir.2
# ls -dv test2.dir/subdir.2
drwxr-xr-x+  2 root     root           2 May 20 15:52 test2.dir/subdir.2
     0:user:gozer:list_directory/read_data/add_file/write_data:file_inherit
         /inherit_only:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

As séries de exemplos a seguir identificam as ACLs do arquivo e do diretório que são aplicadas quando ambos sinalizadores, file_inherit e dir_inherit , estão definidos.

Neste exemplo, o usuário gozer tem permissões de leitura, gravação e execução herdadas por arquivos e diretórios recém-criados:

# chmod A+user:gozer:read_data/write_data/execute:file_inherit/dir_inherit:allow 
test3.dir
# ls -dv test3.dir
drwxr-xr-x+  2 root     root           2 May 20 15:53 test3.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/dir_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

# touch test3.dir/file.3
# ls -v test3.dir/file.3
-rw-r--r--+  1 root     root           0 May 20 15:58 test3.dir/file.3
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

# mkdir test3.dir/subdir.1
# ls -dv test3.dir/subdir.1
drwxr-xr-x+  2 root     root           2 May 20 15:59 test3.dir/subdir.1
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/dir_inherit/inherit_only:allow
     1:user:gozer:add_file/write_data:deny
     2:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     3:owner@::deny
     4:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     5:group@:add_file/write_data/add_subdirectory/append_data:deny
     6:group@:list_directory/read_data/execute:allow
     7:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     8:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Nestes exemplos, pelo fato de as permissões do diretório pai para group@ e everyone@ negarem as permissões de gravação e execução, o usuário gozer não tem permissões de gravação e execução. A propriedade aclmode padrão é restricted, o que indica que as permissões write_data e execute não são herdadas.

Neste exemplo, o usuário gozer tem permissões de leitura, gravação e execução herdadas por arquivos recém-criados. Entretanto, as ACLs não são propagadas para conteúdos subsequentes do diretório.

# chmod A+user:gozer:read_data/write_data/execute:file_inherit/no_propagate:allow 
test4.dir
# ls -dv test4.dir
drwxr-xr-x+  2 root     root           2 May 20 16:02 test4.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/no_propagate:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Como mostra o exemplo a seguir, quando um novo subdiretório é criado, a permissão para arquivos read_data/write_data/execute do usuário gozer não se propaga para o novo diretório sub4.dir:

mkdir test4.dir/sub4.dir
# ls -dv test4.dir/sub4.dir
drwxr-xr-x   2 root     root           2 May 20 16:03 test4.dir/sub4.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Conforme ilustra o exemplo a seguir, as permissões read_data/write_data/execute do usuário gozer se propagam para o arquivo recém-criado:

# touch test4.dir/file.4
# ls -v test4.dir/file.4
-rw-r--r--+  1 root     root           0 May 20 16:04 test4.dir/file.4
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Exemplo 8–7 Herança de ACL com a propriedade `aclmode` definida como `passthrough`

Como mostra o exemplo a seguir, quando a propriedade aclmode no sistema de arquivos tank/cindys é definida como passthrough , o usuário gozer herda as ACLs aplicadas ao diretório test4.dir para o arquivo file.4 recém-criado:

# zfs set aclmode=passthrough tank/cindys
# touch test4.dir/file.4
# ls -v test4.dir/file.4
-rw-r--r--+  1 root     root           0 May 20 16:08 test4.dir/file.4
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Essa saída mostra que a ACL read_data/write_data/execute:allow:file_inherit/dir_inherit que foi definida no diretório pai test4.dir é passada para o usuário gozer.

Exemplo 8–8 Herança de ACL com a propriedade `aclmode` definida como `discard`

Se a propriedade aclmode estiver definida como discard em um sistema de arquivos, as ACLs podem ser potencialmente descartadas quando as permissões de um diretório forem alteradas. Por exemplo:

# zfs set aclmode=discard tank/cindys
# chmod A+user:gozer:read_data/write_data/execute:dir_inherit:allow test5.dir
# ls -dv test5.dir
drwxr-xr-x+  2 root     root           2 May 20 16:09 test5.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :dir_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Se, mais tarde, você decidir comprimir as permissões em um diretório, a ACL não-comum é descartada. Por exemplo:

# chmod 744 test5.dir
# ls -dv test5.dir
drwxr--r--   2 root     root           2 May 20 16:09 test5.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data/execute:deny
     3:group@:list_directory/read_data:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /execute/write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/read_attributes/read_acl
         /synchronize:allow

Exemplo 8–9 Herança de ACL com a propriedade `aclinherit` definida como `noallow`

No exemplo abaixo, estão definidas duas ACLs não-comuns com herança de arquivo. Uma ACL concede a permissão read_data e outra ACL nega a permissão read_data. Este exemplo também mostra como você pode especificar duas ACEs no mesmo comando chmod.

# zfs set aclinherit=noallow tank/cindys
# chmod A+user:gozer:read_data:file_inherit:deny,user:lp:read_data:file_inherit:allow 
test6.dir
# ls -dv test6.dir
drwxr-xr-x+  2 root     root           2 May 20 16:11 test6.dir
     0:user:gozer:read_data:file_inherit:deny
     1:user:lp:read_data:file_inherit:allow
     2:owner@::deny
     3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     4:group@:add_file/write_data/add_subdirectory/append_data:deny
     5:group@:list_directory/read_data/execute:allow
     6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Conforme mostra o exemplo abaixo, quando um novo arquivo é criado, a ACL que concede a permissão read_data é descartada.

# touch test6.dir/file.6
# ls -v test6.dir/file.6
-rw-r--r--   1 root     root           0 May 20 16:13 test6.dir/file.6
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Definindo e exibindo ACLs em arquivos ZFS no formato compacto

Você pode definir e exibir as permissões em arquivos ZFS em um formato compacto que usa unicamente 14 letras para representar as permissões. As letras que representam as permissões compactas estão listadas na Tabela 8–2 e Tabela 8–3.

Você pode exibir listagens de ACLs compactas de arquivos e diretórios usando o comando ls -V. Por exemplo:

# ls -V file.1
-rw-r--r--   1 root     root      206663 Jun 17 10:07 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

A saída de ACL compacta é descrita da seguinte forma:

owner@: O proprietário não tem permissões de execução para o arquivo (x= execute).
owner@: O proprietário pode ler e modificar o conteúdo do arquivo ( rw=read_data/write_data), (p= append_data). O proprietário também pode modificar os atributos do arquivo, tais como registros de data, atributos estendidos e ACLs (A=write_xattr , W=write_attributes e C=write_acl). Além disso, o proprietário pode modificar a propriedade do arquivo (o=write_owner).
group@: O grupo não tem permissões de modificação e execução para o arquivo (write_data, p=append_data e x=execute).
group@: O grupo tem permissões de leitura para o arquivo (r= read_data).
everyone@: Todos os que não são proprietários do arquivo ou membros do grupo de proprietários do arquivo não têm permissão para executar ou modificar o conteúdo do arquivo nem para modificar os atributos do arquivo (w= write_data, x=execute, p =append_data, A=write_xattr , W=write_attributes, C= write_acl e o=write_owner).
everyone@: Todos aqueles que não são proprietários de arquivos ou membros de um grupo de proprietários do arquivo em um arquivo e em seus atributos (r= read_data, a=append_data, R=read_xattr, c=read_acl e s=synchronize). A permissão de acesso synchronize não está implementada atualmente.

A ACL de formato compacto oferece as seguintes vantagens em relação à ACL de formato verboso:

As permissões podem ser especificadas como argumentos posicionais para o comando chmod.
O caractere hífen (-), que identifica a ausência de permissões, pode ser removido. Apenas as letras requisitadas precisam ser especificadas.
Ambos sinalizadores, de permissões e de herança, estão definidos no mesmo modo.

Para obter mais informações sobre o uso de ACL de formato compacto, consulte Definindo e exibindo ACLs em arquivos ZFS no formato verboso.

Exemplo 8–10 Definindo e exibindo ACLs em formato compacto

No exemplo a seguir, existe uma ACL comum no file.1:

# ls -V file.1
-rw-r--r--   1 root     root      206663 Jun 17 10:07 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

No exemplo seguinte, as permissões read_data/execute são adicionadas ao usuário gozer no diretório file.1:

# chmod A+user:gozer:rx:allow file.1
# ls -V file.1
-rw-r--r--+  1 root     root      206663 Jun 17 10:07 file.1
        user:gozer:r-x-----------:------:allow
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Outra forma de adicionar as mesmas permissões para o usuário gozer é inserir uma nova entrada ACL em uma posição específica, 4, por exemplo. As ACLs existentes nas posições 4–6 são levadas para baixo. Por exemplo:

# chmod A4+user:gozer:rx:allow file.1
# ls -V file.1
-rw-r--r--+  1 root     root      206663 Jun 17 10:16 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
        user:gozer:r-x-----------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

No exemplo abaixo, o usuário gozer tem permissões de leitura, gravação e execução herdadas por arquivos e diretórios recém-criados.

# chmod A+user:gozer:rwx:fd:allow dir.2
# ls -dV dir.2
drwxr-xr-x+  2 root     root           2 Jun 17 10:19 dir.2
        user:gozer:rwx-----------:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:-w-p----------:------:deny
            group@:r-x-----------:------:allow
         everyone@:-w-p---A-W-Co-:------:deny
         everyone@:r-x---a-R-c--s:------:allow

Você também pode recortar e colar os sinalizadores de permissões e de herança da saída ls -V no formato compacto chmod. Por exemplo, para duplicar os sinalizadores de permissões e de herança no diretório dir.2 do usuário gozer para o usuário cindys em dir.2, copie e cole os sinalizadores de permissão e de herança (rwx-----------:f-----:allow ) no comando chmod, como mostra a seguir:

# chmod A+user:cindys:rwx-----------:fd----:allow dir.2
# ls -dV dir.2
drwxr-xr-x+  2 root     root           2 Jun 17 10:19 dir.2
       user:cindys:rwx-----------:fd----:allow
        user:gozer:rwx-----------:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:-w-p----------:------:deny
            group@:r-x-----------:------:allow
         everyone@:-w-p---A-W-Co-:------:deny
         everyone@:r-x---a-R-c--s:------:allow

Exemplo 8–11 Herança de ACL com a propriedade `aclinherit` definida como `passthrough`

Um sistema de arquivos que apresenta a propriedade aclinherit definida como passthrough herda todas as entradas da ACL sem as modificações feitas em tais entradas quando estas são herdadas. Quando esta propriedade estiver definida como passthrough, os arquivos serão criados com permissões determinadas pelas ACEs herdáveis. Se não existirem ACEs herdáveis que afetem as permissões, então as permissões serão definidas de acordo com as permissões solicitadas do aplicativo.

Os exemplos seguintes utilizam a sintaxe compacta de ACL para mostrar como herdar permissões definindo a propriedade aclinherit como passthrough.

Neste exemplo, uma ACL está definida no diretório test1.dir para forçar a herança. A sintaxe cria uma entrada ACL de owner@, group@ e everyone@ para os arquivos recém-criados. O diretórios recém-criados herdam uma entrada ACL de @owner, group@ e everyone@. Adicionalmente, os diretórios herdam outras seis ACEs que propagam as ACEs para os arquivos e diretórios recém-criados.

# zfs set aclinherit=passthrough tank/cindys
# pwd
/tank/cindys
# mkdir test1.dir

# chmod A=owner@:rwxpcCosRrWaAdD:fd:allow,group@:rwxp:fd:allow,everyone@::fd:allow 
test1.dir
# ls -Vd test1.dir
drwxrwx---+  2 root     root           2 Jun 17 10:37 test1.dir
            owner@:rwxpdDaARWcCos:fd----:allow
            group@:rwxp----------:fd----:allow
         everyone@:--------------:fd----:allow

Neste exemplo, um arquivo recém-criado herda a ACL que foi especificada para ser herdada pelos arquivos recém-criados.

# cd test1.dir
# touch file.1
# ls -V file.1
-rwxrwx---+  1 root     root           0 Jun 17 10:38 file.1
            owner@:rwxpdDaARWcCos:------:allow
            group@:rwxp----------:------:allow
         everyone@:--------------:------:allow

Neste exemplo, o diretório recém-criado herda as ACEs que controlam o acesso a este diretório, bem como as ACEs para futuras propagações para os filhos do diretório recém-criado.

# mkdir subdir.1
# ls -dV subdir.1
drwxrwx---+  2 root     root           2 Jun 17 10:39 subdir.1
            owner@:rwxpdDaARWcCos:fdi---:allow
            owner@:rwxpdDaARWcCos:------:allow
            group@:rwxp----------:fdi---:allow
            group@:rwxp----------:------:allow
         everyone@:--------------:fdi---:allow
         everyone@:--------------:------:allow

As entradas -di-- e f-i--- servem para propagar herança e não são consideradas durante o controle de acesso. Neste exemplo, é criado um arquivo com uma ACL comum em outro diretório no qual as ACEs herdadas não estão presentes.

# cd /tank/cindys
# mkdir test2.dir
# cd test2.dir
# touch file.2
# ls -V file.2
-rw-r--r--   1 root     root           0 Jun 17 10:40 file.2
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Exemplo 8–12 Herança de ACL com a propriedade `aclinherit` definida como `passthrough-x`

Quando a propriedade aclinherit está definida como passthrough-x , os arquivos são criados com permissão x para executar para owner@, group@ ou everyone@, mas somente se a permissão de executar estiver definida no modo de criação de arquivo em uma ACE herdável que afeta o modo.

Os exemplos a seguir mostram como herdar a permissão de executar ao definir a propriedade aclinherit como passthrough-x.

# zfs set aclinherit=passthrough-x tank/cindys

A ACL a seguir é definida em /tank/cindys/test1.dir para fornecer uma herança ACL executável para arquivos para owner@, group@ e everyone@.

# chmod A=owner@:rwxpcCosRrWaAdD:fd:allow,group@:rwxp:fd:allow,everyone@::fd:allow test1.dir
# ls -Vd test1.dir
drwxrwx---+  2 root     root           2 Jun 17 10:41 test1.dir
            owner@:rwxpdDaARWcCos:fd----:allow
            group@:rwxp----------:fd----:allow
         everyone@:--------------:fd----:allow

Um arquivo (file1) é criado com as permissões solicitadas 0666. As permissões resultantes são 0660. A permissão de execução não foi herdada já que o modo de criação não a solicitou.

# touch test1.dir/file1
# ls -V test1.dir/file1
-rw-rw----+  1 root     root           0 Jun 17 10:42 test1.dir/file1
            owner@:rw-pdDaARWcCos:------:allow
            group@:rw-p----------:------:allow
         everyone@:--------------:------:allow

A seguir, um executável denominado t é gerado com o uso do compilador cc no diretório testdir.

# cc -o t t.c
# ls -V t
-rwxrwx---+  1 root     root        7396 Jun 17 10:50 t
                 owner@:rwxpdDaARWcCos:------:allow
                 group@:rwxp----------:------:allow
              everyone@:--------------:------:allow

As permissões resultantes são 0770 porque o cc solicitou permissões 0777, que causou a herança da permissão de executar das entradas owner@, group@ e everyone@.