Existe uma razão para a existência de permissões de 'proprietário'? As permissões de grupo não são suficientes?

Acho que entendo como as permissões de arquivo funcionam no Linux. No entanto, eu realmente não entendo por que 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? Ou seja - as permissões de proprietário / grupo foram projetadas e criadas em conjunto com alguma justificativa ou elas vieram uma após a outra para atender a uma necessidade?
• Existe um cenário em que o usuário / grupo / outro esquema é útil, mas um grupo / outro esquema não é suficiente?

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

Os casos de uso que considerei são:

• arquivos particulares - é possível obter com muita facilidade criando um grupo por usuário, algo que geralmente é feito como em muitos sistemas.
• permitindo que apenas o proprietário (por exemplo, serviço do sistema) grave em um arquivo, permita que apenas um determinado grupo leia e negue todos os outros acessos - o problema com este exemplo é que, quando o requisito é que um grupo tenha acesso de gravação, o usuário / group / other falha com isso. A resposta para ambos é usar ACLs e não justifica, IMHO, a existência de permissões de proprietário.

NB Refinei esta questão depois de ter a questão encerrada em superuser.com .

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

História

Originalmente, o Unix tinha apenas 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, a compatibilidade com versões anteriores, se nada mais, requer permissões para o usuário proprietário.

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

Poder expressivo

Ter três permissões para um arquivo permite permissões mais refinadas do que apenas duas, a um custo muito baixo (muito menor que as ACLs). Por exemplo, um arquivo pode ter o modo rw-r-----: gravável apenas 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 de rwsr-x---propriedade root:adminpermite que apenas usuários do admingrupo executem esse programa como raiz.

"Existem permissões que esse esquema não pode expressar" é um argumento terrível contra ele. O critério aplicável é: existem casos expressos comuns suficientes que justificam o custo? Nesse caso, o custo é mínimo, especialmente considerando os outros motivos do usuário / grupo / outro tríptico.

Simplicidade

Ter um grupo por usuário possui 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 email) sabe que tudo o que precisa fazer é dar 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 um grupo ou mais de um?

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

Ortogonalidade

Cada processo realiza acessos ao sistema de arquivos como um usuário específico e um grupo específico (com regras mais complicadas em unidades modernas, que suportam grupos suplementares). O usuário é usado para muitas coisas, incluindo testes de permissão para entrega de raiz (uid 0) e entrega de sinal (com base no usuário). Existe uma simetria natural entre usuários e grupos distintos nas permissões de processo e usuários e grupos distintos nas permissões do sistema de arquivos.

Esse design é deliberado ou é um patch? Ou seja - as permissões de proprietário / grupo foram projetadas e criadas em conjunto com alguma justificativa ou elas vieram uma após a outra para atender a uma necessidade?

O usuário / grupo / outras permissões em um arquivo fazem parte do design original do Unix.

Existe um cenário em que o esquema de usuário / grupo / outro é útil, mas um esquema de grupo / proprietário não é suficiente?

Sim, praticamente todos os cenários que eu poderia imaginar em que a segurança e o controle de acesso são importantes.

Exemplo: convém conceder a alguns binários / scripts em um sistema acesso somente de execução othere manter o acesso de leitura / gravação restrito root.

Não tenho certeza do que você tem em mente para um modelo de permissão do 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 othercategoria.

Edição: Supondo que você quis dizer aqui as group/otherpermissões são tudo o que seria necessário, sugiro que você crie uma maneira de gerenciar chaves criptográficas ou uma maneira que apenas os usuários certos possam acessar seu spool de correio. Há casos em que uma chave privada pode precisar de user:userpropriedade estrita, mas outros casos em que faz sentido atribuí-la user:group.

arquivos particulares - é possível obter com muita facilidade criando um grupo por usuário, algo que geralmente é feito como em muitos sistemas.

Concedido que isso é feito com facilidade, mas é tão facilmente com a existência de um othergrupo ...

permitindo que apenas o proprietário (por exemplo, serviço do sistema) grave em um arquivo, permita que apenas um determinado grupo leia e negue todos os outros acessos - o problema com este exemplo é que, uma vez que o requisito é que um grupo tenha acesso de gravação, o usuário / group / other falha com isso. A resposta para ambos é usar ACLs e não justifica, IMHO, a existência de permissões de proprietário.

Destacamos a parte de sua declaração que parece reiterar meu argumento sobre a necessidade lógica de uma othercategoria nas permissões do sistema de arquivos Unix.

Um projeto de sistema de arquivos como você parece contemplar (pelo que sei) seria inseguro ou pesado. O Unix foi projetado por pessoas muito inteligentes, e acho que o modelo deles oferece o melhor equilíbrio possível de segurança e flexibilidade.

Esse design é deliberado ou é um patch? Ou seja - as permissões de proprietário / grupo foram projetadas e criadas em conjunto com alguma justificativa ou elas vieram uma após a outra para atender a uma necessidade?

Sim, este é um design deliberado que está presente no UNIX desde os primeiros dias. Foi implementado em sistemas em que a memória era medida em KB e as CPUs eram extremamente lentas pelos padrões atuais. O tamanho e a velocidade de tais pesquisas foram importantes. As ACLs precisariam de mais espaço e seriam mais lentas. Funcionalmente, o everyonegrupo é representado pelos outros sinalizadores de segurança.

Existe um cenário em que o esquema de usuário / grupo / outro é útil, mas um esquema de grupo / proprietário não é suficiente?

As permissões que eu normalmente uso para acessar arquivos são: (Estou usando valores de bits para simplificar e porque é assim que costumo defini-los.)

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

Para diretórios e programas, eu normalmente uso:

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

As opções acima são as mais usadas, mas não uma lista exaustiva das 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ório. 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.

O usuário / grupo / outro sistema de permissão foi projetado antes da criação das ACLs. Ele remonta aos primórdios do UNIX, então você não pode dizer que o problema deve ser resolvido com ACLs. Mesmo que o conceito de uma ACL pareça óbvio, isso envolveria uma quantidade significativa (por dia) de sobrecarga extra para armazenar e gerenciar uma quantidade variável de informações de permissão em cada arquivo, em vez de uma quantidade fixa.

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

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