Um motivo: quando alguém cria um arquivo, ele pode estar em apenas um grupo e esse grupo não é especificado durante a criação do arquivo. Então, deve haver uma noção de grupo ativo único.
Tanto quanto eu entendo os usuários no sistema Unix podem pertencer a vários grupos e um deles se tornará o grupo principal para esse usuário. Outros serão grupos suplementares. Toda essa infra-estrutura de usuário / grupo é facilitada pelos arquivos / etc / group e / etc / passwd.
Agora a permissão de grupo do usuário é determinada exclusivamente pelo grupo ativo, que pode ser alterado pelo comando newgrp . O grupo ativo no login é o grupo principal definido no arquivo / etc / passwd. Então a questão é qual é a razão fundamental de por que os designers escolheram ter esse conceito de um único grupo ativo, embora permitindo que o usuário tenha mais de um grupo suplementar? Qual seria o problema se todos os grupos estivessem ativos simultaneamente?
Um motivo: quando alguém cria um arquivo, ele pode estar em apenas um grupo e esse grupo não é especificado durante a criação do arquivo. Então, deve haver uma noção de grupo ativo único.
Todos os grupos estão ativos em todos os momentos.
Você pode acessar qualquer arquivo que qualquer um dos seus grupos possa acessar. Mas quando você cria um novo arquivo / processo, ele é criado usando seu grupo primário, a menos que defina ou Padrões de ACL estão em uso.
Q1: So the question is what is the fundamental reason on why the designers chose to have this concept of a single active group even though allowing the user to have more than one supplementary groups?
O principal objetivo original dos grupos no Unix era permitir o compartilhamento de acesso a arquivos em discos. Nesse caso de uso, você normalmente acessaria seus arquivos a maior parte do tempo e, ocasionalmente, acessaria arquivos que eram compartilhados entre um grupo de usuários.
Então, minha suspeita é de que ele foi projetado em torno desse modelo para começar. Com o passar do tempo, esse modelo foi modificado, mas a abordagem geral permanece intacta, você está em um grupo primário (especificado em /etc/passwd ) e tem grupos suplementares dos quais você pode ser membro (especificados em /etc/group ).
Várias das implementações anteriores (como no Sun / Solaris) incluíam um limite de ~ 15 grupos no total que um usuário poderia ser um membro ao usar o NIS +.
Q2: What would be the issue if all the groups were active simultaneously?
Existem várias chamadas de sistema dentro do POSIX que expõem uma API com este design, portanto, provavelmente seria uma tarefa grande modificá-lo, dada a quantidade de software que é construída em torno dele neste momento. E também não há motivo para alterá-lo.
As outras grandes limitações são o sistema de arquivos e o espaço do processo. Para sistemas de arquivos, estes geralmente incluem apenas um único valor para o GID para o qual um determinado arquivo ou diretório deve ser "agrupado". O mesmo também para processos em execução. Eles são tipicamente associados a um único grupo.
No entanto, essa abordagem geral foi capaz de se adaptar à integração com o Active Directory e outras tecnologias de credenciais ao longo do tempo, por isso é uma implementação perfeitamente adequada, apesar de um pouco estranha quando você a conhece.