O problema é que sempre pensei que essas permissões entrariam em colapso, começando pela mais geral (outra -> grupo -> usuário).
Se fosse esse o caso, "outras" permissões se aplicariam a todos.
Em outras palavras, se o = rwx quem se importa com o que as persmissões para grupo e usuário são?
Isso é diferente da sua frase anterior. Aqui você está sugerindo que as permissões são unidas, por exemplo, que o userX tenha permissão de leitura se o userX for o proprietário do arquivo e o arquivo for legível pelo usuário ou se um grupo ao qual o userX pertence for o proprietário do arquivo e o arquivo for group -readable, ou se o arquivo for de outra leitura. Mas não é assim que funciona. De fato, o=rwxsignifica que as rwxpermissões se aplicam a outras pessoas, mas não diz nada sobre entidades que não são outras.
Primeiro, não importa diretamente a quais grupos um usuário pertence. O kernel não tem uma noção de usuários pertencentes a grupos. O que o kernel mantém é, para cada processo, um ID do usuário (o UID efetivo ) e uma lista de IDs de grupo (o GID efetivo e os GIDs complementares). Os grupos são determinados no momento do login, pelo processo de login - é o processo de login que lê o banco de dados do grupo (por exemplo /etc/group). Os IDs de usuário e grupo são herdados por processos filhos¹.
Quando um processo tenta abrir um arquivo, com permissões tradicionais do Unix:
- Se o usuário proprietário do arquivo for o UID efetivo do processo, os bits de permissão do usuário serão usados.
- Caso contrário, se o grupo proprietário do arquivo for o GID efetivo do processo ou um dos IDs de grupo suplementares do processo, os bits de permissão do grupo serão usados.
- Caso contrário, os outros bits de permissão serão usados.
Somente um conjunto de bits rwx é usado. O usuário tem precedência sobre o grupo, que tem precedência sobre outro. Quando há listas de controle de acesso , o algoritmo descrito acima é generalizado:
- Se houver uma ACL no arquivo para o UID efetivo do processo, ele será usado para determinar se o acesso é concedido.
- Caso contrário, se houver uma ACL no arquivo para o GID efetivo do processo ou um dos IDs de grupo suplementares do processo, os bits de permissão do grupo serão usados.
- Caso contrário, os outros bits de permissão serão usados.
Consulte também Precedência da ACLS quando um usuário pertence a vários grupos para obter mais detalhes sobre como as entradas da ACL são usadas, incluindo o efeito da máscara.
Assim, -rw----r-- alice internsindica um arquivo que pode ser lido e gravado por Alice e que pode ser lido por todos os outros usuários, exceto estagiários. Um arquivo com permissões e propriedade ----rwx--- alice internsé acessível apenas para estagiários, exceto Alice (se ela é estagiária ou não). Como Alice pode ligar chmodpara alterar as permissões, isso não fornece nenhuma segurança; é um caso de ponta. Em sistemas com ACLs, o mecanismo generalizado permite remover permissões de usuários ou grupos específicos, o que às vezes é útil.
Usar um único conjunto de bits, em vez de ordenar todos os bits para cada ação (leitura, gravação, execução), possui várias vantagens:
- Ele tem o efeito útil de permitir remover permissões de um conjunto de usuários ou grupos em sistemas com ACLs. Em sistemas sem ACLs, as permissões podem ser removidas de um grupo.
- É mais simples de implementar: verifique um conjunto de bits, em vez de combinar vários conjuntos de bits.
- É mais simples analisar as permissões de um arquivo, porque menos operações estão envolvidas.
¹ Eles podem mudar quando um processo setuid ou setgid é executado. Isso não está relacionado ao problema em questão.