Basicamente, todo arquivo em um sistema de arquivos do Linux pertence a um usuário e a um grupo. Os grupos proprietários e todos os outros podem ser autorizados a gravar, ler ou executar esses arquivos.

Nesse caso, um grupo pode ser definido como um conjunto de usuários conectados que têm determinados direitos coletivos. Por exemplo, chame um grupo que trabalhe em determinado projeto de project3. Cada usuário de um sistema Linux é um membro de pelo menos um grupo proprietário, normalmente users. Podem existir quantos grupos forem necessários no sistema, mas somente o root é capaz de adicionar grupos. Com o comando groups, todo usuário pode descobrir de quais grupos ele faz parte.

Em determinadas situações, as permissões de acesso podem ser muito restritivas. No entanto, o Linux possui configurações adicionais para permitir a mudança temporária do usuário atual e da identidade do grupo para uma ação específica. Por exemplo, o programa passwd normalmente requer permissões de root para acessar /etc/passwd. Este arquivo contém algumas informações importantes, como os diretórios pessoais de usuários e IDs de usuário e grupo. Sendo assim, um usuário normal não poderia mudar passwd, já que seria muito arriscado conceder a todos os usuários acesso direto a este arquivo. Uma possível solução para esse problema é o mecanismo setuid. O setuid (definir ID do usuário) é um atributo de arquivo especial que instrui o sistema a executar programas marcados adequadamente com um ID de usuário específico. Considere o comando passwd:

-rwsr-xr-x  1 root shadow 80036 2004-10-02 11:08 /usr/bin/passwd

Você pode ver o s que denota que setuid bit está definido para a permissão do usuário. Por meio do setuid bit, todos os usuários iniciando o comando passwd o executam como root.

O setuid bit se aplica a usuários. Entretanto, existe também uma propriedade equivalente para grupos: o setgid bit. Um programa para o qual esse bit foi definido é executado com o ID do grupo no qual ele foi gravado, independentemente do usuário que iniciou o programa. No entanto, em um diretório com o setgid bit, todos os arquivos e diretórios criados recentemente são atribuídos ao grupo ao qual o diretório pertence. Considere o seguinte diretório de exemplo:

drwxrws--- 2 tux archive 48 Nov 19 17:12 
  backup

Você pode ver o s que denota que o setuid bit está definido para a permissão do usuário. O proprietário do diretório e membros do grupo archive poderão acessar este diretório. Os usuários que não são membros deste grupo são “mapeados” para o grupo respectivo. O ID de grupo efetivo de todos os arquivos gravados será archive. Por exemplo, um programa de backup que é executado com o ID de grupo archive é capaz de acessar este diretório mesmo sem privilégios de root.

Também existe o sticky bit. Existe uma diferença caso ele pertença a um programa executável ou a um diretório. Se ele pertencer a um programa, qualquer arquivo marcado dessa forma será carregado na memória RAM a fim de evitar a necessidade de obtê-lo no disco rígido toda vez que for usado. Esse atributo é usado raramente, pois os discos rígidos modernos são muito rápidos. Se este bit estiver designado a um diretório, ele impedirá que usuários apaguem arquivos de outros usuários. Exemplos típicos incluem os diretórios /tmp e /var/tmp:

drwxrwxrwt   2 root  root   1160 2002-11-19 17:15 /tmp 
  

O conceito de permissão tradicional para objetos do sistema de arquivos do Linux, como arquivos ou diretórios, pode ser expandido com o uso de ACLs. Elas admitem a atribuição de permissões a usuários individuais ou a grupos que não sejam o proprietário original ou a um grupo proprietário de um objeto do sistema de arquivos.

Arquivos ou diretórios com permissões de acesso estendidas podem ser detectados com um simples comando ls -l:

-rw-r--r--+ 1 tux project3 14197 Jun 21  15:03 Roadmap

O proprietário do Roadmap é o tux que pertence ao grupo project3. O tux contém acesso de gravação e leitura a este arquivo. O grupo e todos os usuários têm acesso de leitura. A única diferença que diferencia esse arquivo de um arquivo sem uma ACL é o + extra na primeira coluna com os bits de permissão.

Obtenha detalhes sobre a ACL executando getfacl Roadmap:

# file:  Roadmap
# owner: tux
# group: project3
user::rw-
user:jane:rw-       effective: r--
group::r--
group:djungle:rw-   effective: r--
mask::r--
other::---

As três primeiras linhas da saída não retêm informações que não estejam disponíveis com ls -l. Essas linhas informam somente o nome do arquivo, o proprietário e o grupo proprietário. As linhas de 4 a 9 contêm as entradas de ACL. As permissões de acesso convencional representam um subconjunto das possíveis permissões quando se usa ACLs. A ACL do exemplo concede acesso de leitura e gravação ao proprietário do arquivo, assim como ao usuário jane (linhas 4 e 5). O conceito convencional foi expandido permitindo o acesso a um usuário extra. O mesmo se aplica ao acesso de grupo. O grupo proprietário possui permissões de leitura (linha 6) e o grupo djungle possui permissões de leitura e gravação. A entrada mask na linha 8 reduz as permissões efetivas para o usuário jane e o grupo djungle para acesso de leitura. Outros usuários e grupos não recebem nenhum tipo de acesso ao arquivo (linha 9).

Foram fornecidas apenas informações básicas. Encontre mais informações detalhadas sobre ACLs no Capítulo 24, Listas de controle de acesso no Linux.