Novo modelo de ACL do Solaris

As versões anteriores do Solaris 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 os seguintes:

Baseado na especificação NFSv4 e semelhante às ACLs de estilo NT.
Proporciona privilégios de acesso muito mais granulares. Para obter mais informações, consulte a Tabela 8-2.
É definido e exibido com os comandos chmod e ls em vez dos comandos setfacl e getfacl .
Oferece semânticas de herança mais ricas para designar como os privilégios de acesso serão aplicados do diretório aos 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 de esquema POSIX usam uma única entrada para definir que permissões serão aceitas e que permissões serã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 de nenhuma ACE que define um conjunto de permissões se as permissões definidas nesta ACE serão aceitas ou negadas.

A tradução entre ACLs de estilo NFSv4 e de esquema POSIX é a seguinte:

Se usar utilitários com ACL, como os comandos cp, mv, tar, cpio ou rcp, para transferir arquivos UFS com ACLs para um sistema de arquivos ZFS, as ACLs de esquema POSIX são traduzidas para as ACLs de estilo NFSv4 equivalentes.
Algumas ACLs de estilo NFSv4 são traduzidas para ACLs de esquema POSIX. Se uma ACL de estilo NFSv4– não for traduzida para uma ACL de esquema 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 possuírem ACLs de estilo POSIX, elas são convertidas em ACLs de estilo NFSv4.
Se tentar definir uma ACL de estilo NFSv4 em um arquivo UFS, será exibida uma mensagem semelhante à seguinte:
```
chmod: ERROR: ACL type's are different
```

Se tentar definir uma ACL de esquema 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

São fornecidos dois formatos básicos de ACL:

Sintaxe para definição de ACLs comuns

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 obter uma descrição dos tipos de entrada ACL, consulte a Tabela 8-1.
user or group:ACL-entry-ID=username or groupname: Identifica o tipo de entrada ACL da sintaxe de ACL explícita. O tipo de entrada ACL do usuário ou do grupo deve conter também o ID da entrada ACL, nome do usuário ou nome do grupo. Para obter uma descrição dos tipos de entrada 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 a seguir, nenhum valor ACL-entry-ID existe para owner@, group@ ou everyone@..

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

O 2 ou a designação do ID de índice neste exemplo identifica a entrada ACL na ACL maior, que pode ter várias entradas para owner, UIDs específicos, group e everyone. Você pode especificar o ID de índice com o comando chmod para identificar que parte da ACL quer modificar. Você pode identificar, por exemplo, o ID de índice ID 3 como A3 para o comando chmod, semelhante a:

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. Deve incluir o ID da entrada ACL, que contém um `nome de usuário` ou um `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. Deve incluir o ID da entrada ACL, que contém um `nome de grupo` ou um `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 diretório dentro de um diretório.
execute	i	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	f	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 da máscara de acesso, a entidade pode executar `ls`(1) e `stat`(2).
read_data	a	Permissão para ler o conteúdo do arquivo.
read_xattr	A	Permissão para ler os atributos estendidos de um arquivo ou realizar uma pesquisa no diretório dos atributos estendidos do arquivo.
synchronize	s	Espaço reservado. Ainda não implementado.
write_xattr	Q	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	Um	Permissão para alterar para um valor arbitrário os períodos de tempo associados a um arquivo ou diretório.
write_acl	C	Permissão para gravar a ACL ou habilidade para modificar a ACL com o 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 o grupo do qual o usuário é um 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 usar a herança da ACL é que um arquivo ou diretório recém-criado possa herdar as ACLs que pretendem herdar, mas levando em consideração os bits de permissão 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 somente a ACL do diretório pai até os arquivos do diretório.
`dir_inherit`	`d`	Herda somente a ACL do diretório pai até os 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, você pode definir a diretriz de herança da ACL padrão no sistema de arquivos para que seja mais rigorosa ou menos rigorosa usando a propriedade aclinherit do sistema de arquivos. Para obter mais informações, consulte a próxima seção.

Propriedade da ACL (`aclinherit`)

O sistema de arquivos ZFS inclui a propriedade aclinherit para determinar o comportamento de herança ACL. Os valores incluem o seguinte:

discard – Para novos objetos, nenhuma entrada ACL é herdada quando um arquivo ou diretório é criado. A ACL no arquivo ou diretório é igual ao modo de permissão 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 um modo determinado pelas ACEs herdáveis. Se não houver ACEs herdáveis que afetem o modo, então o modo será definido de acordo com o modo solicitado do aplicativo.
passthrough-x – 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 que afeta o modo.

O modo padrão do aclinherit é restricted.

Ignorar Links de Navegao
Sair do Modo de Exibio de Impresso
	Guia de administração do ZFS Oracle Solaris