Como um usuário pode ser impedido de alterar um arquivo que tenha permissões de gravação para outros usuários?

Question

Uma situação estranha surgiu recentemente. User1 precisava ser capaz de alterar arquivos em um diretório onde os arquivos e o diretório eram de propriedade de User2 e do grupo User2. Para facilitar essa edição, as permissões foram alteradas para 757 recursivamente para a estrutura de diretórios. Assim, uma listagem parecia algo como o seguinte.

drwxr-xrwx 3 user2 user2 4096 Nov 19 19:41 .
drwxr-xr-x 3 user2 user2 4096 Nov 19 19:41 ..
drwxr-xrwx 3 user2 user2 4096 Nov 19 19:41 directory1
drwxr-xrwx 3 user2 user2 4096 Nov 19 19:41 directory2
drwxr-xrwx 3 user2 user2 4096 Nov 19 19:41 directory3
-rwxr-xrwx 3 user2 user2   42 Nov 19 19:41 file1

O User1 conseguiu ler os arquivos, mas tentativas de criar novos arquivos ou editar / copiar os arquivos existentes falharam. O erro foi algo como o seguinte.

$ touch file1
touch: cannot touch 'file1': Permission denied

Pensando que talvez a unidade estivesse protegida contra gravação de alguma forma, o Usuário1 pediu ao Usuário2 para alterar o arquivo. User2 foi capaz de fazê-lo sem quaisquer problemas, indicando assim que a unidade não foi protegida contra gravação.

Olhando para df e /etc/fstab , o arquivo parecia estar em um disco rígido montado localmente.

Outras informações. User1 está no grupo User2. (Isto foi originalmente pensado para não ser o caso) Não houve bloqueios no arquivo. Parecia que o SE Linux estava desativado. (Como indicado por sestatus ) Embora eu reconheça que normalmente você não deseja definir um diretório inteiro para permitir que alguém grave nele, esse é um caso especial. Quase uma construção idêntica em uma máquina separada funcionou. A saída de getfacl é a mesma para os arquivos e diretórios.

# file: .
# owner: user
# group: user
user::rwx
group::r-x
other::rwx

O que pode causar essa proteção e como ela pode ser desfeita?

    

Answer 1

Eu simplesmente excluiria a pergunta, pois um dos fatos originais estava incorreto. Eu decidi que, uma vez que a resposta óbvia foi perdida e há uma alternativa não tão óbvia, a resposta para postar as possíveis causas e soluções para este problema ajuda aqueles que podem ter um problema semelhante no futuro.

1) Se você tem esse problema e acha que o usuário1 não faz parte do usuário2, verifique isso com o usuário1 marcando os grupos ou examinando o arquivo passwd. Nesse caso, o usuário1 foi adicionado por engano com a seguinte entrada /etc/passwd e nenhuma entrada em /etc/group .

user1:x:1001:1000:User1:/home/user1:/bin/bash

enquanto o usuário 2 tinha o seguinte em /etc/passwd

user2:x:1000:1000:User2:/home/user2:/bin/bash

e

user2:x:1000:user2 user1

As permissões do grupo têm prioridade sobre as Outras permissões, portanto, a escrita não foi permitida. Isso pode ser corrigido alterando as permissões do grupo ou removendo user1 do grupo user2. Esta foi a resposta fácil que tinha as suposições iniciais corretas, muitas pessoas provavelmente teriam chegado. Nota para si mesmo, quando algo não funciona, verifique por si mesmo.

2) A resposta menos óbvia vem do uso de Access Control Lists (ACLs) de arquivos. Se o usuário em questão tiver permissões específicas atribuídas, elas terão prioridade sobre as permissões gerais. Embora isso possa ser conhecido por aqueles que usaram ACLs, suspeito que muitos nem sabem que eles existem. Aqui está um exemplo de como isso pode bloquear um usuário.

$ sudo setfacl -m u:user:r-x .
$ ls -la
total 0
drwxr-xrwx+  2 root root  60 Nov 21 20:46 .
drwxrwxrwt. 12 root root 300 Nov 21 20:45 ..
-rw-rw-r--.  1 user user   0 Nov 21 20:46 dog
$ touch cat
touch: cannot touch ‘cat’: Permission denied
$ getfacl .
# file: .
# owner: root
# group: root
user::rwx
user:user:r-x
group::r-x
mask::r-x
other::rwx

Para desfazer isso

$ sudo setfacl -b .
$ sudo getfacl .
# file: .
# owner: root
# group: root
user::rwx
group::r-x
other::rwx

$ touch cat
$ ls -la cat
-rw-rw-r--. 1 user user 0 Nov 21 20:51 cat

Obrigado @andcoz por perguntar sobre os grupos que finalmente me fizeram voltar e verificar novamente e agradecer @Rianto Wahyudi por mencionar 'getacl' que eu não havia visto / usado antes.