Guia de administração do ZFS Oracle Solaris

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:

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.