Definindo ACLs em arquivos ZFS

Por serem implementadas com ZFS, as ACLs estão compostas de uma matriz de 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.

Os arquivos ZFS ainda possuem bits de permissão e um modo, mas esses valores são mais de um cache do que a ACL representa. Se você alterar as permissões do arquivo, a ACL do arquivo será conseqüentemente atualizada . Além disso, se você remover uma ACL não-comum que permite que o usuário acesse o 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 ao grupo ou a 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 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 (permitir) foi concedida, ela não pode ser negada por uma entrada ACL deny (negar) subseqüente no mesmo conjunto de permissões da ACL.

• A permissão write_acl é concedida incondicionalmente ao proprietário, 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 negadas ou quando falta um acesso de permissão, o subsistema de privilégios determina que 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 usar 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 Jun 23 15:06 file.1
     0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     1:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
     2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Cada categoria de usuário (owner@, group@, everyone@) possui uma entrada de ACL neste exemplo.

Encontra-se abaixo uma descrição dessa ACL do arquivo:

0:owner@

O proprietário pode ler e modificar o conteúdo do arquivo ( read_data/write_data/append_data/read_xattr). O proprietário também pode modificar os atributos do arquivo, tais como carimbos de data/hora, atributos estendidos e ACLs (write_xattr/read_attributes/write_attributes/ read_acl/write_acl). Além disso, o proprietário pode modificar a propriedade do arquivo (write_owner:allow).

A permissão de acesso synchronize não está implementada atualmente.

1:group@

O grupo recebe permissões de leitura para o arquivo e os atributos do arquivo (read_data/read_xattr/read_attributes/read_acl:allow).

2:everyone@

Todos os que não são nem usuário nem grupo têm permissões de leitura para o arquivo e os atributos do arquivo (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, a ACL padrão do diretório é semelhante ao ilustrado abaixo:

$ ls -dv dir.1
drwxr-xr-x   2 root     root           2 Jun 23 15:06 dir.1
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     1:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     2:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Abaixo encontra-se uma descrição do diretório de ACL:

0: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 ), procura o conteúdo (execute) e lê e modifica os atributos do arquivo, como registros de data/hora, atributos estendidos e ACLs (/read_xattr/write_xattr/read_attributes/write_attributes/read_acl/write_acl ). Além disso, o proprietário pode modificar a propriedade do diretório (write_owner:allow).

A permissão de acesso synchronize não está implementada atualmente.

1:group@

O grupo pode listar e ler o conteúdo do diretório e os atributos do diretório. Além disso, o grupo tem permissão para executar pesquisas no conteúdo do diretório (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow ).

2:everyone@

Todos os que não são nem usuário nem grupo têm permissão de leitura e execução para o conteúdo e os 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.