Permissão padrão para arquivos / pastas recém-criados usando ACLs não respeitadas por comandos como "descompactar"

3

Estou com problemas para configurar um sistema para vários usuários acessando o mesmo conjunto de arquivos. Eu li e examinei docs e joguei com ACLs, mas ainda não consegui.

MEU CENÁRIO:

Tem vários usuários, por exemplo, user1 e user2 , que pertencem a um grupo chamado sharedusers . Eles devem ter todas as permissões WRITE para um mesmo conjunto de arquivos e diretórios, digamos subjacente em /userdata/sharing/ .

Eu tenho o grupo da pasta definido como sharedusers e SGID para ter todos os arquivos / pastas recém-criados dentro do mesmo grupo.

ubuntu@home:/userdata$  ll
drwxr-sr-x  2 ubuntu sharedusers 4096 Nov 24 03:51 sharing/

Eu configuro as ACLs para este diretório para que eu possa ter permissão de subdir dirs / arquivos herdados de seus pais.

ubuntu@home:/userdata$  setfacl -m group:sharedusers:rwx sharing/
ubuntu@home:/userdata$  setfacl -d -m group:sharedusers:rwx sharing/

Veja o que eu tenho:

ubuntu@home:/userdata$   getfacl sharing/
# file: sharing/
# owner: ubuntu
# group: sharedusers
# flags: -s-
user::rwx
group::r-x
group:sharedusers:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:sharedusers:rwx
default:mask::rwx
default:other::r-x

Parece bem quando eu crio uma nova pasta com novos arquivos e a permissão está correta.

ubuntu@home:/userdata/sharing$ mkdir a && cd a
ubuntu@home:/userdata/sharing/a$ touch a_test
ubuntu@home:/userdata/sharing/a$  getfacl a_test 
# file: a_test
# owner: ubuntu
# group: sharedusers
user::rw-
group::r-x                  #effective:r--
group:sharedusers:rwx       #effective:rw-
mask::rw-
other::r--

Como você pode ver, o grupo sharedusers tem permissão efetiva rw- .

No entanto, se eu tiver um arquivo zip e usar o comando unzip -q para descompactar o arquivo dentro da pasta sharing , as pastas extraídas não terão permissão de gravação de grupo . Portanto, os usuários do grupo sharedusers não podem modificar arquivos nessas pastas extraídas.

ubuntu@home:/userdata/sharing$  unzip -q Joomla_3.0.2-Stable-Full_Package.zip 
ubuntu@home:/userdata/sharing$  ll
drwxrwsr-x+  2 ubuntu sharedusers    4096 Nov 24 04:00 a/
drwxr-xr-x+ 10 ubuntu sharedusers    4096 Nov  7 01:52 administrator/
drwxr-xr-x+ 13 ubuntu sharedusers    4096 Nov  7 01:52 components/

Você identifica a diferença de permissões entre a pasta a (criada antes) e a pasta administrator extraída por unzip . E as ACLs de um arquivo dentro de administrator :

ubuntu@home:/userdata/sharing$  getfacl administrator/index.php 
# file: administrator/index.php
# owner: ubuntu
# group: ubuntu
user::rw-
group::r-x                #effective:r--
group:sharedusers:rwx     #effective:r--
mask::r--
other::r--

Ele também tem ubuntu group, não sharedusers group como esperado.

Alguém poderia explicar o problema e me dar conselhos? Obrigado antecipadamente!

    
por Ngoc Pham 24.11.2012 / 05:10

1 resposta

6

Esse comportamento é o ACL_MASK no trabalho. Observando o arquivo index.php , ele teoricamente obtém a permissão pretendida group:sharedusers:rwx , mas efetivamente outro #effective:r-- . Isso ocorre porque o valor teórico obtém XOR com o mask::r-- para fornecer o valor efetivo, que é o que você vê com ls -l (ou ll ).

Agora, o ACL_MASK de mask::r-- é, na verdade, um recurso de segurança da ACL, impedindo que você conceda acesso onde não pretendia: Ao adicionar um arquivo existente (em vez de criar um novo), o ACL configura o ACL_MASK para o valor anterior do arquivo, que neste caso era r-- .

Isso não está limitado a descompactar. Isso se aplica sempre que você adiciona um arquivo em vez de criar ele. Você poderia tentar cp ou tar , por exemplo, e acabaria com o mesmo resultado.

Na verdade, a documentação ( man 5 acl ) informa no parágrafo CRIAÇÕES DE OBJETOS E ACLS DEFAULT que os valores default se aplicam apenas ao objeto criado com qualquer uma das seguintes chamadas de sistema: creat () , mkdir () , mknod () , mkfifo () ou open () .

Portanto, não posso oferecer uma boa solução, pois você não poderá usar o mecanismo padrão da ACL para o que está fazendo.

    
por 27.11.2012 / 18:33