Existe uma razão pela qual existem permissões 'owner'? As permissões do grupo não são suficientes?

Question

Acho que entendo como as permissões de arquivo funcionam no linux. No entanto, eu não entendo porque eles são divididos em três níveis e não em dois.

Gostaria que os seguintes problemas fossem respondidos:

• Esse design deliberado ou um patch? Isso é - as permissões de proprietário / grupo foram projetadas e criadas juntamente com alguma lógica ou elas vieram uma após a outra para responder a uma necessidade?
• Existe um cenário em que o esquema usuário / grupo / outro é útil, mas um esquema de grupo / outro não será suficiente?

As respostas para o primeiro devem citar livros didáticos ou fóruns de discussão oficiais.

Casos de uso que eu considerei são:

• arquivos privados - muito facilmente obtidos, criando um grupo por usuário, algo que geralmente é feito como em muitos sistemas.
• permitindo que somente o proprietário (por exemplo, serviço do sistema) grave em um arquivo, permitindo que apenas um determinado grupo leia e negue todos os outros acessos - o problema com este exemplo é que o requisito é para um grupo para ter acesso de gravação, o usuário / grupo / outro falha com isso. A resposta para ambos é usar ACLs e não justifica, IMHO, a existência de permissões de proprietário.

NB Eu refinei esta questão depois de ter a questão encerrada em superuser.com e stackoverflow.com

EDIT corrigido "mas um esquema de grupo / proprietário não será suficiente" para "... grupo / outro ...".

    

Answer 1

História

Originalmente, o Unix só tinha permissões para o usuário proprietário e para outros usuários: não havia grupos. Veja a documentação do Unix versão 1, em particular chmod(1) . Portanto, compatibilidade com versões anteriores, se nada mais, requer permissões para o usuário proprietário.

Os grupos vieram depois. As ACLs que permitem envolver mais de um grupo nas permissões de um arquivo vieram muito mais tarde.

Potência expressiva

Ter três permissões para um arquivo permite permissões mais refinadas do que ter apenas duas, a um custo muito baixo (muito menor que as ACLs). Por exemplo, um arquivo pode ter o modo rw-r----- : gravável somente pelo usuário proprietário, legível por um grupo.

Outro caso de uso são os executáveis setuid que são executáveis apenas por um grupo. Por exemplo, um programa com o modo rwsr-x--- de propriedade de root:admin permite que apenas usuários do grupo admin executem esse programa como root.

“Existem permissões que este esquema não pode expressar” é um argumento terrível contra ele. O critério aplicável é, existem suficientes casos expressivos comuns que justifiquem o custo? Nesse caso, o custo é mínimo, especialmente considerando as outras razões para o usuário / grupo / outro tríptico.

Simplicidade

Ter um grupo por usuário tem uma sobrecarga de gerenciamento pequena, mas não insignificante. É bom que o caso extremamente comum de um arquivo privado não dependa disso. Um aplicativo que cria um arquivo privado (por exemplo, um programa de entrega de e-mail) sabe que tudo o que precisa fazer é fornecer ao arquivo o modo 600. Ele não precisa percorrer o banco de dados do grupo procurando o grupo que contém apenas o usuário - e o que fazer se não houver tal grupo ou mais de um?

Vindo de outra direção, suponha que você veja um arquivo e deseje auditar suas permissões (por exemplo, verifique se elas são o que devem ser). É muito mais fácil quando você pode “só acessível ao usuário, bem, próximo” do que quando precisa rastrear as definições do grupo. (Essa complexidade é a ruína de sistemas que fazem uso pesado de recursos avançados, como ACLs ou recursos.)

Ortogonalidade

Cada processo executa acessos ao sistema de arquivos como um usuário em particular e um grupo particular (com regras mais complicadas em unices modernos, que suportam grupos suplementares). O usuário é usado para muitas coisas, incluindo testes para a permissão raiz (uid 0) e entrega de sinal (baseada no usuário). Há uma simetria natural entre distinguir usuários e grupos nas permissões de processo e distinguir usuários e grupos nas permissões do sistema de arquivos.

    

Answer 2

Is this deliberate design or a patch? That is - was the owner/group permissions designed and created together with some rationale or did they come one after another to answer a need?

As permissões de usuário / grupo / outro em um arquivo fazem parte do design original do Unix.

Is there a scenario where the user/group/other scheme is useful but a group/owner scheme will not suffice?

Sim, praticamente todos os cenários que imagino onde a segurança e o controle de acesso são importantes.

Exemplo: você pode querer dar alguns binários / scripts em um acesso somente de execução do sistema para other , e manter o acesso de leitura / gravação restrito a root .

Não tenho certeza do que você tem em mente para um modelo de permissão de sistema de arquivos que tenha apenas permissões de proprietário / grupo. Não sei como você poderia ter um sistema operacional seguro sem a existência de uma categoria other .

EDITAR: Supondo que você quis dizer aqui que group/other permissões são tudo o que seria necessário, sugiro criar uma maneira de gerenciar chaves criptográficas ou uma maneira que apenas os usuários certos possam acessar o spool de correio. Há casos em que uma chave privada pode precisar estritamente de user:user de propriedade, mas em outros casos em que faz sentido atribuir user:group de propriedade.

private files - very easily obtainable by making a group per-user, something that is often done as is in many systems.

Com certeza, isso é feito facilmente, mas é tão fácil quanto com a existência de um grupo other ...

allowing only the owner (e.g. system service) to write to a file, allowing only a certain group to read, and deny all other access - the problem with this example is that once the requirement is for a group to have write access, the user/group/other fails with that. The answer for both is using ACLs, and doesn't justify, IMHO, the existence of owner permissions.

Eu destaquei a parte da sua declaração que parece reiterar meu ponto sobre a necessidade lógica de uma categoria other nas permissões do sistema de arquivos Unix.

Tal projeto de sistema de arquivos, como você parece estar contemplando (pelo que eu posso dizer), seria inseguro ou incômodo. O Unix foi projetado por algumas pessoas muito inteligentes, e acho que o modelo deles oferece o melhor equilíbrio possível de segurança e flexibilidade.

    

Answer 3

Is this deliberate design or a patch? That is - was the owner/group permissions designed and created together with some rationale or did they come one after another to answer a need?

Sim, este é um design deliberado que está presente no UNIX desde os primeiros dias. Ele foi implementado em sistemas em que a memória foi medida em KB e as CPUs ficaram extremamente lentas nos padrões atuais. Tamanho e velocidade de tais pesquisas era importante. As ACLs precisariam de mais espaço e seriam mais lentas. Funcionalmente, o grupo everyone é representado pelos outros sinalizadores de segurança.

Is there a scenario where the user/group/other scheme is useful but a group/owner scheme will not suffice?

As permissões que eu geralmente uso para acesso a arquivos são: (Estou usando valores de bit para simplificar e porque é assim que normalmente os configuro.)

• 600 ou 400 : Acesso apenas pelo usuário (e sim eu concedo acesso somente leitura ao usuário).
• 640 ou 660 : acesso de usuários e grupos.
• 644 , 666 ou 664 : usuário, grupo e outro acesso. Qualquer esquema de permissão de dois níveis só pode lidar com dois desses três casos. O terceiro exigiria ACLs.

Para diretórios e programas comumente usados:

• 700 ou 500 : acesso apenas ao usuário
• 750 ou 710 : acesso somente de grupo
• 755 , 777 , 775 ou 751 : usuário, grupo e outro acesso. Os mesmos comentários aplicam-se aos arquivos.

Os itens acima são os mais usados, mas não uma lista exaustiva de configurações de permissão que eu uso. As permissões acima combinadas com um grupo (às vezes com um bit de grupo fixo nos diretórios) foram suficientes em todos os casos em que eu poderia ter usado uma ACL.

Como foi observado acima, é muito fácil listar a permissão em uma listagem de diretórios. Se as ACLs não forem usadas, posso auditar as permissões de acesso apenas com uma listagem de diretórios. Quando trabalho com sistemas baseados em ACL, acho muito difícil verificar ou auditar permissões.

    

Answer 4

O usuário / grupo / outro sistema de permissão foi projetado antes que as ACLs fossem inventadas. Ele remonta aos primórdios do UNIX, então você não pode dizer que o problema deve ser resolvido com as ACLs. Mesmo que o conceito de um ACL pareça óbvio, ele teria envolvido uma quantidade significativa de sobrecarga extra para armazenar e gerenciar uma quantidade variável de informações de permissão com cada arquivo, em vez de um valor fixo.

Usar ACLs para tudo também significa que você não tem um subconjunto bem definido das informações de permissão que podem ser exibidas "de relance". A saída para ls -l mostra as permissões padrão (usuário / grupo / outro), o nome do usuário e grupo e uma notação adicional (por exemplo, + ou @ sign) nas entradas que possuem uma ACL associada a elas , tudo em uma linha. Seu sistema exigiria que ele identificasse os "dois primeiros" grupos na ACL para fornecer funcionalidade equivalente.

Como um ponto adicional, um arquivo ainda precisa ter um proprietário no modelo UNIX porque as ACLs do UNIX não fornecem permissão para modificar a ACL.