Confuso com "grupos" e o "modelo de permissão" do Linux

Mas eu realmente não entendo o conceito de um grupo. Pelo que percebi, um grupo é apenas um grupo de usuários. (Mas isso significa que um usuário pode pertencer a vários grupos?)

Sim e sim.

Um grupo, pelo que entendi, destina-se basicamente a facilitar a definição / desativação de permissões rwx por atacado para um grupo de usuários (ou seja, o grupo).

Uma maneira de tornar as permissões muito mais fáceis é quando o grupo precisa de acesso a muitos arquivos ou pastas espalhados pelo sistema.

Por exemplo, sempre que um novo usuário ingressar, você precisará encontrar todos esses arquivos um por um e tentar adivinhar coisas como "se os usuários A, B, C tiverem acesso, o usuário D deve ser adicionado". Mas se essas permissões simplesmente listarem um nome de grupo, você não precisará atualizá-las - em vez disso, basta adicionar o usuário a um grupo e pronto.

(Não se limita apenas a permissões de arquivo – alguns serviços do sistema também podem ser configurados para conceder acesso a um grupo em vez de usuários individuais, com as mesmas vantagens aqui.)

Isso significa que, além de um arquivo ter um proprietário (ou seja, o ID do usuário da pessoa que criou o arquivo), também existe um "proprietário do grupo" para esse arquivo? E esse grupo normalmente é um dos grupos aos quais o proprietário do arquivo pertence?

Sim. Cada usuário tem um "grupo primário" e os arquivos recém-criados pertencem a esse grupo. No entanto, mesmo usuários não root podem usar chown/chgrp para reatribuir seus próprios arquivos a qualquer grupo ao qual eles pertençam atualmente.

(Há uma exceção: se o diretório tiver o bit 'setgid' definido, os arquivos recém-criados herdarão o grupo do diretório , não o do criador. Isso está mais próximo de como o Windows NTFS funciona por padrão.)

Obviamente, esse sistema de "proprietário do grupo" é um pouco limitador quando os arquivos podem ter apenas um grupo por vez. Veja a próxima seção sobre isso.

E se eu tiver três grupos A,B,C no meu sistema e quiser definir as permissões rw-, -wx, rx respectivamente no sistema?

Em seguida, você usa outro recurso chamado "ACLs" (listas de controle de acesso), que – como o nome indica – permite especificar uma lista arbitrária de usuários e grupos aos quais dar acesso.

O Linux suporta o formato POSIX ACL, que é basicamente uma extensão direta do modelo existente. Ou seja, se você primeiro reescrever as permissões existentes como:

user::rwx, group::r-x, other::---

agora você pode usar setfaclou chaclpara adicionar seus três grupos adicionais como:

group:Family:rw-, group:Friends:-wx, group:Coworkers:r-x

Nota para evitar confusão: POSIX ACLs tentam permanecer compatíveis tanto quanto possível com o chmod tradicional, mas isso leva a um recurso surpreendente. Assim que você adicionar ACLs a um arquivo, o campo "grupo" ls -lcomeçará a mostrar algo chamado 'máscara', e um comando como chmod g-wnegará o acesso de gravação a todas as entradas ACL , não apenas ao "grupo proprietário".

Por que o Linux, ou mesmo o Unix, usa a categorização 'proprietário/grupo/outro' se puder usar apenas ACLs? Isso ocorre porque essa categorização simples é anterior ao suporte da ACL em décadas.

O Unix originalmente optou pela abordagem simples, como a maioria dos outros sistemas operacionais na época - devido a restrições de espaço em disco (os bits de permissão cabem em apenas dois bytes) e/ou decisão de design deliberada (Multics pode ter elaborado ACLs na época , mas muitas coisas no Unix foram intencionalmente simplificadas).

Eventualmente, as APIs tornaram-se imutáveis ​​- novas poderiam ser adicionadas, mas o "chmod" existente não poderia ser alterado, porque os programas já esperavam que funcionasse de uma determinada maneira. (O OpenVMS também teve que manter seu sistema de bits de permissão semelhante, mesmo depois de adicionar ACLs.)

Além disso, infelizmente é o único sistema compatível entre todos os sistemas operacionais do tipo Unix. Alguns outros Unixes (por exemplo, FreeBSD, Solaris) podem usar um formato ACL bem diferente, e ainda outros (OpenBSD) não têm nenhum suporte ACL. Compare também com o Windows, onde todas as proteções de arquivo são baseadas em ACL.

O conceito de grupos Linux/Unix pode ser confuso. Mas vamos tentar descompactar isso.

Arquivos e diretórios têm um proprietário e um grupo (ou um "proprietário de grupo", como você diz). Eles também têm três conjuntos de rwxbits de permissão, um para usuário, um para grupo e outro para outro. Além disso, eles têm mais três bits de permissões: setuid, setgid e sticky. O usuário e o grupo de um arquivo ou diretório são armazenados internamente como um UID e um GID, que são números inteiros sem sinal que servem como identificadores internos para usuários e grupos.

Os usuários no sistema têm um UID e um GID (normalmente configurados no /etc/passwdarquivo), a configuração do GID desse arquivo é usada para indicar o grupo primário de um usuário. Além disso, um usuário pode pertencer a mais grupos (normalmente configurados no /etc/grouparquivo, que lista usuários adicionais para cada grupo no sistema).

Você pode verificar o UID, GID, grupo principal e grupos adicionais do usuário com o idcomando, que listará todas essas informações para o usuário que está executando o comando.

Ao tentar acessar um arquivo ou diretório, o sistema tentará validar seu acesso com base nos bits de permissão. Em particular, ele começará analisando se deve usar o usuário, grupo ou outros bits. Se o seu UID corresponder exatamente ao UID do usuário que está acessando o arquivo, os bits de "usuário" serão usados. Para o grupo, se o seu grupo primário corresponder ao grupo do arquivo ou se algum dos grupos adicionais (conforme relatado por id) corresponder a esse grupo, os bits do "grupo" serão usados. Caso contrário, se nenhum deles corresponder, os "outros" bits serão usados.

O significado das permissões para arquivos é bastante direto, rsignifica que você pode abrir o arquivo para leitura, wsignifica que você pode abrir esse arquivo para gravação (modificando assim seu conteúdo) e xsignifica que você pode executar esse arquivo como um executável (seja um binário ou um script .)

Para diretórios, é um pouco mais sutil. rsignifica que você pode listar os arquivos nesse diretório (por exemplo, com ls /path/to/dir), wsignifica que você pode criar novos arquivos nesse diretório (ou excluir arquivos existentes desse diretório). Mas você precisa xser capaz de acessar qualquer um dos arquivos nesse diretório , se você não tiver xum diretório, não poderá acessar cdesse diretório e realmente não poderá abrir arquivos dentro desse diretório, mesmo que saiba que eles existem. (Isso permite configurações peculiares, onde com rmas sem x, você pode listar os nomes dos arquivos, mas não pode abrir nenhum dos arquivos, enquanto com xmas semrvocê pode abrir arquivos no diretório apenas se já souber seus nomes, pois não pode listar os nomes de arquivo no diretório.)

Supondo que você tenha permissões para criar um novo arquivo em um diretório, um novo arquivo que você criar terá seu usuário como proprietário e, por padrão, terá seu grupo principal como "proprietário do grupo". Mas nem sempre é assim!

Lembra que mencionei o bit setgid anteriormente? Bem, se um diretório tiver o lance setgid definido (você pode defini-lo com chmod g+s /path/to/dir), os novos arquivos criados nesse diretório herdarão o grupo do próprio diretório, em vez do grupo principal do usuário que o cria. Além disso, se você criar um novo subdiretório em um diretório ativado por setgid, o subdiretório também terá o bit setgid ativado. (Isso é necessário para preservar a propriedade de herança de grupo para toda a subárvore.)

Essa técnica de bit setgid em diretórios é bastante útil para implementar diretórios compartilhados. Nós vamos chegar a isso em breve.

Mais uma observação interessante é que os sistemas Unix da família BSD (como FreeBSD, NetBSD, OpenBSD) sempre se comportam como o bit setgid é definido em um diretório. Dessa forma, o grupo primário de um usuário é um pouco menos significativo, já que ser o grupo durante a criação do arquivo é normalmente o recurso mais visível desse grupo.

Outro conceito de interesse é o "umask", que é um conjunto de bits que fica "mascarado" quando um novo arquivo ou diretório é criado. Você pode verificar sua umask no shell usando o umaskcomando e também pode usar esse comando com um argumento para modificar a umask atual. Os valores típicos são umask 002, umask 022, umask 027, etc.

Os bits no umask referem-se aos rwxbits e os três dígitos octais mapeiam para o usuário, grupo e outros bits em um modo de permissão. Portanto umask 002, preservará todos os bits para usuário e grupo (0 significa sem mascaramento), enquanto eles bloquearão o wbit para outro (2 é w.) Eles manterão os arquivos graváveis ​​pelo usuário e pelo grupo, mas apenas legíveis por outros. umask 027por outro lado, terá gravável apenas pelo usuário, apenas legível/executável, mas não gravável por grupo e nenhum acesso para outros (7 significa mascarar todos os rwx.)

O umaské usado toda vez que um novo arquivo é criado. Os aplicativos geralmente especificam as permissões que desejam, normalmente da maneira mais liberal , para que o umask possa restringir isso a permissões mais realistas. Por exemplo, aplicativos normais solicitarão que os arquivos sejam criados com rw-rw-rw-permissões 0666 ( ), esperando que o umask descarte pelo menos o bit gravável pelo mundo. Os diretórios serão normalmente criados com 0777 ( rwxrwxrwx), assumindo o mesmo.

Então, como podemos juntar tudo isso?

A configuração normalmente usada por distribuições Linux baseadas em Red Hat (como RHEL, CentOS e Fedora) é bastante flexível, vale a pena dar uma olhada.

Para cada usuário criado, um grupo com o mesmo nome também é criado (normalmente com um GID correspondente ao UID do usuário) e esse grupo é definido como o grupo principal desse usuário. Esse grupo deve conter apenas o usuário com o mesmo nome. Portanto, os arquivos do meu usuário são normalmente criados como filbranden:filbranden, com meu próprio grupo primário bloqueando os bits de permissão do grupo.

Como o grupo é essencialmente o mesmo que apenas o próprio usuário, o umaské definido como 002, o que significa que todos os arquivos e diretórios serão graváveis ​​em grupo por padrão.

Então, como você bloqueia os diretórios para torná-los privados? Simples, basta remover os bits de permissão para "outros" do diretório de nível superior. Por exemplo, se eu usar chmod 770 ~(ou 700também está bem, 770funciona porque o grupo principal é meu), nenhum outro usuário poderá acessar nenhum dos arquivos em meu diretório pessoal. Que os arquivos dentro dele tenham lido ou executado bits para "outros" não importa, pois perder o xbit no próprio diretório superior significa que eles nunca serão capazes de atravessá-lo.

Então, como você implementa diretórios compartilhados? Simples. Comece criando um grupo e adicionando todos os usuários que devem colaborar nesse projeto a esse grupo. Em seguida, crie um (ou mais) diretórios para esse projeto. Defina o "proprietário do grupo" dos diretórios para o grupo que você acabou de criar. Por fim, habilite o bit setgid nesses diretórios. Todos os membros desse grupo poderão criar arquivos nesses diretórios. Como todos eles têm umask 002, os arquivos que eles criarem serão graváveis ​​em grupo. E por causa do bit setgid no diretório superior, todos os arquivos serão de propriedade do grupo compartilhado (e não dos grupos primários por usuário). O que significa que os usuários do grupo poderão modificar arquivos que foram criados por outros membros do grupo, pois eles terão permissões de gravação nesses arquivos.

Esses diretórios compartilhados podem ser legíveis por todos (mantendo as permissões re xpara "outro" no diretório superior) ou podem ser privados para o grupo (removendo essas permissões).

Essa é a essência disso. Como as permissões do Unix/Linux normalmente funcionam e o motivo pelo qual funcionam dessa maneira.

Há, é claro, muitas ressalvas. Muitas dessas configurações (como umask) existem em diferentes sessões e é possível que fiquem fora de sincronia. Adicionar um usuário a um grupo significa que ele geralmente precisa fazer login novamente para que a alteração entre em vigor. Embora a criação de um arquivo em um diretório ativado por setgid-bit faça com que o grupo do diretório seja herdado, mover um arquivo existente para esse diretório normalmente não altera a propriedade (portanto, você pode acabar com arquivos no compartilhamento de grupo que não são modificáveis por outros membros do grupo.) A semântica em relação à exclusão de arquivos também pode ser um tanto complicada.

Os sistemas Unix/Linux modernos mantêm toda a lógica por trás de usuários, grupos e propriedade de arquivos. Mas eles normalmente também incluem mecanismos adicionais para impor permissões, como ACLs de arquivo estendidas, que podem ser muito mais granulares ao permitir acesso de leitura/gravação a árvores de diretório e não sofrem de muitos dos problemas com permissões básicas listadas acima.

Sim. Cada arquivo e diretório tem um proprietário e um grupo. Se você digitar o comando ll, ele fornecerá uma lista de arquivos no diretório atual com o proprietário e o grupo listados.

NA TENTATIVA DE MANTER AS COISAS SIMPLES E NÃO BOMBARDEAR COM A COMPLEXIDADE:

Se você fizer chown root:www <FILEPATH>isso, estará definindo o proprietário como root e o grupo como www.

Se você chmod 750 <FILEPATH>estiver definindo a permissão do proprietário para ler/gravar/executar, a permissão do grupo para ler/executar e a outra permissão (todos) para nenhum.

Isso significa que o root terá acesso total e qualquer pessoa no grupo www poderá ler/executar o arquivo. Portanto, se você adicionar o usuário 'sarah' e o usuário 'bill' ao grupo www, eles também terão permissões de leitura/execução no arquivo.

E se eu tiver três grupos A,B,C no meu sistema e quiser definir as permissões rw-, -wx, rx respectivamente no sistema?

Você não define permissões em grupos. Você define permissões em cada arquivo/diretório e atribui a cada arquivo/diretório um proprietário e grupo. Quando você coloca um usuário em um grupo, ele dá acesso a todos os arquivos/diretórios que o grupo tem permissão para acessar.

Digamos que você tenha três arquivos no sistema com a permissão 750:

index.html (raiz:A)

index.txt (raiz:B)

index.php (raiz:C)

O proprietário (root) tem acesso total (leitura/gravação/execução) a todos os arquivos.
Qualquer um no grupo A pode ler/executar index.html (mas não index.txt ou index.php).
Qualquer um no grupo B pode ler/executar index.txt (mas não index.html ou index.php).
Qualquer um no grupo C pode ler/executar index.php (mas não index.html ou index.txt).

A usuária 'sarah' não pode acessar nenhum dos arquivos porque ela não é a proprietária (root) ou em nenhum dos grupos A, B ou C. No entanto, se você adicionar a usuária 'sarah' aos grupos A e B então ela teria permissão de leitura/execução em index.html e index.txt (mas nenhuma permissão em index.php). Se você adicionar o usuário 'bill' aos grupos B e C, ele terá permissão de leitura/execução em index.txt e index.php (mas nenhuma permissão em index.html).

https://linux.die.net/man/1/chown
https://linux.die.net/man/1/chmod