Grupos de usuários e permissões de arquivos no Linux

Introdução

O Linux é um sistema operacional multiusuário. Cada processo e arquivo pertence a um usuário, e cada usuário tem um grupo primário, além de possíveis grupos suplementares. Juntos, identidade, propriedade e bits de permissão determinam quem pode ler, alterar, executar ou acessar um recurso.

Neste laboratório, você criará um pequeno ambiente de equipe usando contas exclusivas para prática. Você criará um usuário, gerenciará a associação a grupos, protegerá um arquivo, verificará o bloqueio de uma conta, controlará as permissões padrão com umask e configurará diretórios com sticky bit e setgid. Todo o trabalho permanecerá no ambiente do laboratório e não alterará o caminho de login padrão de labex.

Verificar identidades e criar um usuário para prática

Nesta etapa, você verificará sua identidade atual e criará uma conta separada para praticar permissões. O Linux representa um usuário por meio de um nome de usuário e de um ID numérico de usuário (UID). Ele também registra um ID numérico de grupo primário (GID) e quaisquer grupos suplementares.

Primeiro, confirme a identidade do shell atual:

whoami

A saída deve ser labex. Agora, exiba o UID, o grupo primário e os grupos suplementares associados a essa conta:

id

Os IDs numéricos exatos podem variar, mas a saída os identifica com os rótulos uid, gid e groups.

Criar uma conta altera arquivos do sistema e, portanto, exige privilégios administrativos. sudo significa “superuser do”: ele executa o comando seguinte com autoridade elevada depois de verificar se a conta atual tem permissão para fazer isso. Use sudo somente no comando que precisa de administração e leia o comando completo antes de pressionar Enter.

O comando useradd abaixo usa três opções:

• -m cria o diretório pessoal.
• -U cria um grupo primário com o mesmo nome da conta.
• -s /bin/bash seleciona o Bash como shell de login da conta.

Crie um usuário para prática chamado jack:

sudo useradd -m -U -s /bin/bash jack

Verifique a nova conta e seu diretório pessoal:

id jack

ls -ld /home/jack

A saída de id deve mostrar jack tanto como usuário quanto como grupo primário. A listagem do diretório deve mostrar que /home/jack existe e pertence a jack:jack.

Gerenciar grupos suplementares

Nesta etapa, você criará um grupo de equipe e adicionará usuários a grupos suplementares. Normalmente, o grupo primário de um usuário se torna o grupo proprietário dos arquivos que ele cria. Os grupos suplementares concedem acesso a outros recursos compartilhados.

Crie um grupo chamado developers:

sudo groupadd developers

As opções usermod -aG significam “adicionar aos grupos suplementares”. A opção -a é importante: sem ela, -G pode substituir as associações suplementares existentes. Adicione jack aos grupos developers e sudo:

sudo usermod -aG developers,sudo jack

Registre também labex como membro de developers. O shell atual não receberá imediatamente a nova identidade de grupo; você a atualizará com segurança na etapa final.

sudo usermod -aG developers labex

Verifique as duas contas:

groups jack

groups labex

A primeira saída deve incluir jack, developers e sudo. A segunda deve incluir developers. A associação a sudo permite que uma conta autenticada solicite privilégios elevados; ela deve ser concedida somente a administradores de confiança.

Controlar a propriedade e as permissões de arquivos

Nesta etapa, você protegerá um relatório da equipe com um proprietário, um grupo e um modo de permissão específicos. Uma listagem longa mostra primeiro o tipo do arquivo, seguido de três grupos de permissões para o proprietário, o grupo e os demais usuários.

Crie um relatório vazio no diretório do projeto:

touch /home/labex/project/secure-report.txt

Altere os dois proprietários usando o formato user:group de chown:

sudo chown jack:developers /home/labex/project/secure-report.txt

Defina o modo 640:

sudo chmod 640 /home/labex/project/secure-report.txt

Na notação numérica, leitura vale 4, escrita vale 2 e execução vale 1. Portanto:

• O proprietário com 6 tem permissão de leitura e escrita (4 + 2).
• O grupo com 4 tem somente permissão de leitura.
• Os demais usuários com 0 não têm acesso.

Verifique o resultado:

ls -l /home/labex/project/secure-report.txt

stat -c 'owner=%U group=%G mode=%a' /home/labex/project/secure-report.txt

Os campos estáveis de stat devem informar owner=jack group=developers mode=640.

Verificar e alterar o bloqueio de uma conta

Nesta etapa, você praticará o bloqueio e o desbloqueio temporários de uma conta exclusiva para prática. O Linux armazena hashes de senhas e o status das contas em /etc/shadow. Um ! no início do campo de senha indica que a autenticação por senha está bloqueada.

A configuração criou uma conta para prática chamada contractor. Exiba somente o primeiro caractere do campo de senha para que o hash nunca seja impresso. Leia o pipeline da esquerda para a direita: getent shadow contractor obtém o registro shadow da conta; o primeiro cut usa : como delimitador e seleciona o campo 2; o segundo cut mantém o caractere 1 desse campo:

sudo getent shadow contractor | cut -d: -f2 | cut -c1

O caractere inicial normalmente deve ser $, que indica o início de um formato moderno de hash de senha. Bloqueie a conta com usermod -L:

sudo usermod -L contractor

Verifique novamente o primeiro caractere:

sudo getent shadow contractor | cut -d: -f2 | cut -c1

Agora ele deve ser !. Desbloqueie a conta com usermod -U e confirme que o ! desapareceu:

sudo usermod -U contractor

sudo getent shadow contractor | cut -d: -f2 | cut -c1

Neste cenário, o contractor deixou a equipe. Bloqueie a conta uma última vez, preservando os arquivos:

sudo usermod -L contractor

Bloquear a autenticação por senha não exclui a conta, não remove seu diretório pessoal e não encerra necessariamente as sessões existentes. Isso é diferente de excluir um usuário e é útil quando os arquivos precisam ser mantidos para análise.

Controlar as permissões padrão com Umask

Nesta etapa, você usará umask para controlar os bits de permissão removidos quando o shell cria novos arquivos e diretórios. Normalmente, os programas começam com um modo máximo de 666 para arquivos regulares e 777 para diretórios. Uma máscara 027 remove a permissão de escrita do grupo e todas as permissões dos demais usuários.

Crie um espaço de trabalho para o experimento:

mkdir -p /home/labex/project/umask-demo

Salve a máscara atual para restaurá-la depois. A sintaxe $(command) é chamada de substituição de comando: o shell executa o comando dentro dos parênteses e substitui toda a expressão pela saída dele. A atribuição armazena esse resultado em original_umask; assim como em outras atribuições do shell, não há espaços ao redor de =.

original_umask=$(umask)

Aplique a máscara 027 e crie um arquivo e um diretório:

umask 027

touch /home/labex/project/umask-demo/private-note.txt

mkdir /home/labex/project/umask-demo/private-dir

Verifique os modos numéricos resultantes:

stat -c '%a %n' /home/labex/project/umask-demo/private-note.txt /home/labex/project/umask-demo/private-dir

O arquivo deve ter o modo 640, enquanto o diretório deve ter o modo 750. Os arquivos não recebem bits de execução automaticamente. Restaure a máscara original do shell:

umask "$original_umask"

Alterar umask afeta os objetos criados depois da alteração; isso não reescreve as permissões dos objetos existentes.

Proteger um diretório compartilhado com o sticky bit

Nesta etapa, você configurará uma área pública de recebimento na qual todos poderão criar arquivos, mas os usuários não poderão excluir arquivos pertencentes a outra pessoa. O modo comum 777 concede a todos os usuários acesso completo ao diretório. Adicionar o sticky bit altera as regras de exclusão dentro do diretório.

Crie o diretório compartilhado e defina o modo 1777. O 1 inicial habilita o sticky bit.

mkdir /tmp/shared-dropbox

chmod 1777 /tmp/shared-dropbox

Use sudo -u para criar um arquivo como cada conta de prática:

sudo -u jack touch /tmp/shared-dropbox/jack-note.txt

sudo -u contractor touch /tmp/shared-dropbox/contractor-note.txt

Agora peça para jack tentar excluir o arquivo do contractor:

sudo -u jack rm /tmp/shared-dropbox/contractor-note.txt

Essa falha é intencional. Você deve ver Operation not permitted, e o arquivo do contractor deve permanecer. Verifique o diretório:

ls -ld /tmp/shared-dropbox

As permissões devem terminar com um t minúsculo, como em drwxrwxrwt. O t minúsculo indica que o sticky bit e a permissão de execução para os demais usuários estão definidos. Um T maiúsculo indicaria que o sticky bit está definido sem a permissão de execução correspondente.

Configurar um diretório de equipe com Setgid

Nesta etapa, você preparará um diretório privado de colaboração. Em um diretório, o setgid faz com que os itens criados dentro dele herdem o grupo do diretório, em vez do grupo primário de quem os criou. Isso mantém os arquivos da equipe associados a um único grupo compartilhado.

Crie o diretório:

mkdir /home/labex/project/team-share

Torne jack o proprietário e developers o grupo proprietário:

sudo chown jack:developers /home/labex/project/team-share

Defina o modo 2770. O 2 inicial habilita o setgid; 770 concede acesso completo ao proprietário e ao grupo e nega o acesso aos demais usuários.

sudo chmod 2770 /home/labex/project/team-share

Verifique o resultado:

ls -ld /home/labex/project/team-share

stat -c 'owner=%U group=%G mode=%a' /home/labex/project/team-share

A listagem longa deve mostrar s na posição de execução do grupo, como em drwxrws---. O s minúsculo indica que tanto o setgid quanto a execução para o grupo estão ativos. Um S maiúsculo indicaria que o setgid está presente, mas a execução para o grupo está ausente.

Setuid, representado por um s na posição de execução do proprietário, é outro bit especial frequentemente encontrado em executáveis do sistema cuidadosamente controlados. Saiba reconhecê-lo ao ler permissões, mas não o adicione a programas arbitrários.

Atualizar a associação a grupos e verificar a herança

Nesta etapa, você ativará a associação a developers em um shell filho e comprovará que o setgid controla o grupo de um arquivo novo. Adicionar um usuário a /etc/group não reescreve os grupos suplementares de um shell que já está em execução.

Inicie um shell filho com developers como grupo ativo:

newgrp developers

O prompt pode ser atualizado. Você continua sendo o usuário labex, mas agora o shell filho tem developers como grupo efetivo. Confirme as duas identidades:

id

Crie um arquivo no diretório com setgid:

touch /home/labex/project/team-share/labex-note.txt

Verifique o novo arquivo:

stat -c 'owner=%U group=%G mode=%a' /home/labex/project/team-share/labex-note.txt

O proprietário deve ser labex, enquanto o grupo deve ser developers. O setgid herda o grupo proprietário; os bits de leitura e escrita do arquivo ainda dependem do processo que o criou e de sua umask.

Saia do shell filho e retorne à sessão original do terminal:

exit

O arquivo continuará no diretório depois que o shell filho for encerrado.

Resumo

Você praticou o modelo básico de identidade e acesso usado pelos sistemas Linux. Criou um usuário e um grupo de equipe, gerenciou associações suplementares, atribuiu propriedades e traduziu modos numéricos de permissão em regras práticas de acesso. Você também verificou o bloqueio de uma conta sem expor seu hash de senha.

Em seguida, foi além das permissões comuns: umask controlou os padrões, o sticky bit protegeu arquivos em um diretório público e o setgid preservou a propriedade do grupo da equipe em um diretório privado de colaboração. Por fim, você usou newgrp para atualizar a associação a grupos e verificou o grupo herdado em um arquivo real.