The thing is, I always thought these permissions collapse on each other, starting with the most general one (other -> group -> user).
Se fosse esse o caso, as permissões "outros" se aplicariam a todos.
In other words, if o=rwx who cares what the persmissions for group and user are?
Isso é diferente da sua frase anterior. Aqui, você insinua que as permissões são cumpridas juntas, por exemplo, que o userX tem permissão de leitura se o userX possuir o arquivo e o arquivo for legível pelo usuário, ou se um grupo ao qual o userX pertence possui o arquivo e o arquivo for legível por grupo ou se o arquivo for legível por outros. Mas não é assim que funciona. De fato, o=rwx significa que as permissões rwx se aplicam a outras, mas não diz nada sobre entidades que não são outras.
Primeiro, não importa diretamente quais grupos um usuário pertence. O kernel não tem noção de usuários pertencentes a grupos. O que o kernel mantém é, para cada processo, um ID de usuário (o UID efetivo ) e uma lista de IDs de grupos (o GID efetivo e os GIDs suplementares). 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ários e grupos 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 do ID do grupo suplementar do processo, os bits de permissão do grupo serão usados.
- Caso contrário, os outros bits de permissão são usados.
Apenas um conjunto de bits rwx é usado. O usuário tem precedência sobre o grupo que tem precedência sobre o outro. Quando existem listas de controle de acesso , o algoritmo descrito acima é generalizado:
- Se houver uma ACL no arquivo para o UID efetivo do processo, ela será usada para determinar se o acesso é concedido.
- Caso contrário, se houver uma ACL no arquivo para o GID efetivo do processo ou um ID de grupo suplementar do processo, os bits de permissão do grupo serão usados.
- Caso contrário, os outros bits de permissão são usados.
Veja também Precedência do 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 interns indica um arquivo que pode ser lido e escrito 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 (seja ela interna ou não). Como Alice pode chamar chmod para 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 específicos ou grupos específicos, o que às vezes é útil.
Usar um único conjunto de bits, em vez de orar todos os bits para cada ação (ler, escrever, executar), tem várias vantagens:
- Ele tem o efeito útil de permitir a remoção de 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.