31 out 2026 · linux, segurança, permissões · 5 min

Permissões no Linux: chmod, chown, sudo e o que não fazer

Permissão no Linux é uma tabela de três colunas: dono, grupo e outros. Cada coluna tem três bits, leitura, escrita e execução. É toda a história, e cabe em três dígitos octais. O resto é convenção.

Medi isso num contêiner descartável com três usuários. Arquivo com modo 640, dono root e grupo projeto: alice e bob leem, carol recebe Permission denied. Diretório com modo 2770: arquivo criado por bob herda o grupo projeto e alice lê sem reclamar. Sudo escopado: alice roda um comando como root, bob recebe “a password is required”.

O que os três dígitos dizem

O modo 640 é três dígitos, não um número mágico. O 6 é dono, o 4 é grupo, o 0 é o resto do mundo. Cada dígito é a soma de 4 (leitura), 2 (escrita) e 1 (execução). Dono com 6 tem leitura e escrita. Grupo com 4 tem leitura. Outros com 0 não têm nada.

O primeiro dígito, quando aparece, são bits especiais. O 2 é setgid: arquivos novos na pasta herdam o grupo. O 1 é sticky: só o dono apaga o próprio arquivo. O 4 é setuid, e em script não funciona na maioria dos sistemas; em binário, faz o programa rodar como o dono.

chown troca dono e grupo

chown muda quem é dono. chown alice arquivo troca o dono. chown :projeto arquivo troca só o grupo. chown alice:projeto arquivo troca os dois de uma vez. É o comando que as pessoas esquecem que existe, e depois tentam resolver com chmod 777.

O grupo importa tanto quanto o dono. Um arquivo 640 com grupo errado é um arquivo fechado para quem deveria ler e aberto para quem não deveria.

Pasta compartilhada com setgid

O padrão que funciona para uma pasta de equipe:

mkdir -p /srv/projeto
chown root:projeto /srv/projeto
chmod 2770 /srv/projeto

O 2770 é 2 (setgid) + 770 (dono e grupo fazem tudo, outros nada). Com setgid, todo arquivo criado ali nasce com grupo projeto, mesmo que quem criou seja bob. Sem ele, bob cria arquivo com grupo bob e alice não lê.

Foi exatamente isso que apareceu na medição: bob criou bob.txt e o arquivo nasceu com grupo projeto, e alice leu sem erro.

sudo escopado, não sudo livre

Sudo livre é alice ALL=(ALL) NOPASSWD: ALL. É o mesmo que dar a senha de root. Sudo escopado é listar o comando exato:

alice ALL=(root) NOPASSWD: /usr/local/bin/relatorio-status

Alice pode rodar só esse binário como root. sudo bash falha. sudo cat /etc/shadow falha. E o arquivo em /etc/sudoers.d precisa ter modo 440, senão sudo ignora com aviso.

O artefato

O script abaixo cria o grupo, os dois usuários, a pasta compartilhada e o sudo escopado. Roda como root, não instala nada.

#!/usr/bin/env bash
set -euo pipefail

GRUPO=projeto
PASTA=/srv/projeto
CMD=/usr/local/bin/relatorio-status

groupadd -f "$GRUPO"
id alice >/dev/null 2>&1 || useradd -m -s /bin/bash -G "$GRUPO" alice
id bob >/dev/null 2>&1 || useradd -m -s /bin/bash -G "$GRUPO" bob
usermod -aG "$GRUPO" alice
usermod -aG "$GRUPO" bob

mkdir -p "$PASTA"
chown root:"$GRUPO" "$PASTA"
chmod 2770 "$PASTA"

printf 'segredo do projeto\n' > "$PASTA/segredo.txt"
chown root:"$GRUPO" "$PASTA/segredo.txt"
chmod 640 "$PASTA/segredo.txt"

cat > "$CMD" <<'EOF'
#!/usr/bin/env bash
echo "status ok, rodando como $(id -un)"
EOF
chmod 755 "$CMD"

mkdir -p /etc/sudoers.d
cat > /etc/sudoers.d/90-projeto <<'EOF'
alice ALL=(root) NOPASSWD: /usr/local/bin/relatorio-status
EOF
chmod 440 /etc/sudoers.d/90-projeto

if command -v visudo >/dev/null 2>&1; then
  visudo -cf /etc/sudoers.d/90-projeto
fi

echo "pronto: grupo $GRUPO, pasta $PASTA (2770), segredo (640), sudo escopado para alice"

Como verificar

bash setup-permissoes.sh
runuser -u alice -- cat /srv/projeto/segredo.txt
runuser -u carol -- cat /srv/projeto/segredo.txt
runuser -u alice -- sudo /usr/local/bin/relatorio-status
runuser -u bob -- sudo /usr/local/bin/relatorio-status

A primeira leitura imprime o segredo. A segunda imprime Permission denied. A terceira imprime “status ok, rodando como root”. A quarta pede senha.

Se der errado

• Permission denied para quem deveria ler: o usuário não está no grupo, ou está mas a sessão foi aberta antes da mudança. Grupos são lidos no login. Use newgrp projeto ou abra um shell novo.
• sudo pede senha mesmo com NOPASSWD: o arquivo em /etc/sudoers.d não está com modo 440, ou tem erro de sintaxe. Valide com visudo -cf /etc/sudoers.d/90-projeto.
• arquivo novo na pasta não herda o grupo: faltou o bit setgid. Confira com stat -c %a /srv/projeto; tem que começar com 2.
• chown em link simbólico segue o alvo por padrão. Use chown -h quando quiser mudar o link.

Links que ajudam

Quem endurece acesso remoto já viu a mesma lógica de usuário e grupo em endurecer o SSH e chave SSH em vez de senha. Segredos em arquivo, com permissão 600, aparecem em env e segredos em arquivo. Contêiner sem root usa o mesmo conceito de usuário sem privilégio em como rodar um contêiner sem root.

FAQ

Por que não usar 777 e resolver logo? Porque 777 deixa qualquer usuário local ler e sobrescrever. Em servidor compartilhado isso é acesso de escrita para todo mundo.

chmod +x em arquivo que não é executável faz sentido? Não. O bit x em arquivo de texto não transforma em programa. Use só em scripts e binários.

sudo com senha é pior que sudo sem senha? Não necessariamente. NOPASSWD em comando escopado é aceitável para automação. NOPASSWD em ALL é o problema.

Como ver as permissões em octal? stat -c %a arquivo. Em modo simbólico, ls -l e eza -l.

O que é umask? É a máscara que o shell aplica na criação de arquivo. Umask 022 resulta em 644 para arquivo. Umask 077 resulta em 600.

Fontes: chmod(1), chown(1), sudoers(5). Medição própria em contêiner descartável, 31 out 2026.