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.
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
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.
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.
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.
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.
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. |
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.
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 .