Permissões de arquivos no Linux: chmod, chown e sudo com exemplos

As permissões de arquivos no Linux respondem à pergunta «quem pode fazer o quê com este arquivo». Todo arquivo tem um dono, um grupo e três conjuntos de permissões: para o dono, para o grupo e para todos os outros. As permissões são alteradas com chmod, o dono com chown, e as ações de administrador são executadas com sudo. Veja a seguir como ler as permissões, como alterá-las e como resolver o erro Permission denied.

Como ver as permissões de um arquivo

As permissões aparecem na saída de ls -l:

$ ls -l
-rw-r--r-- 1 alice developers  1204 Oct 10 14:02 notes.txt
-rwxr-xr-x 1 alice developers   356 Oct 10 14:05 deploy.sh
drwxr-x--- 2 alice developers  4096 Oct 10 13:50 secrets

Os dez primeiros caracteres se leem assim:

• O primeiro caractere é o tipo: - arquivo comum, d diretório, l link simbólico.
• Os caracteres 2 a 4 são as permissões do dono (user).
• Os caracteres 5 a 7 são as permissões do grupo (group).
• Os caracteres 8 a 10 são as permissões dos demais (others).

Depois vêm o número de links, o dono (alice), o grupo (developers), o tamanho, a data e o nome. Para um único arquivo, o comando stat é prático:

$ stat -c '%A %a %U:%G %n' deploy.sh
-rwxr-xr-x 755 alice:developers deploy.sh

O que significam r, w e x

O significado das permissões é diferente para arquivos e para diretórios, e essa é a principal causa de confusão.

Observe que quem tem w e x em um diretório pode apagar um arquivo dentro dele, mesmo sem permissão de escrita no próprio arquivo. E sem x no diretório não é possível abrir os arquivos dentro dele, ainda que as permissões do arquivo permitam a leitura.

O sistema verifica as permissões nesta ordem: se você é o dono, aplicam-se as permissões do dono; senão, se você pertence ao grupo do arquivo, aplicam-se as permissões do grupo; senão, aplicam-se as permissões dos demais. O usuário root ignora as verificações de leitura e escrita.

Notação numérica: 755, 644, 600

Cada permissão tem um peso: r = 4, w = 2, x = 1. A soma dos pesos de cada um dos três conjuntos resulta em um dígito de 0 a 7.

Vale memorizar estes conjuntos típicos:

O comando chmod: como alterar permissões

Modo numérico

A forma numérica define todas as permissões de uma vez:

chmod 644 index.html
chmod 755 deploy.sh
chmod 600 ~/.ssh/id_ed25519

Modo simbólico

A forma simbólica altera permissões específicas sem mexer nas demais. Quem: u dono, g grupo, o demais, a todos. Ação: + adiciona, - remove, = define exatamente.

chmod +x deploy.sh        # permitir a execução
chmod u+x,g-w file        # o dono executa; o grupo perde a escrita
chmod o-rwx secrets/      # nenhuma permissão para os demais
chmod g=rx app/           # o grupo apenas lê e entra no diretório

Recursivo: arquivos e diretórios de forma diferente

A opção -R aplica as permissões a toda a árvore de diretórios. Mas chmod -R 755 tornaria executáveis todos os arquivos, o que normalmente não é desejado. O melhor é separar arquivos e diretórios com find:

find /srv/site -type d -exec chmod 755 {} +
find /srv/site -type f -exec chmod 644 {} +

Existe também uma forma curta: a letra maiúscula X acrescenta execução apenas aos diretórios e aos arquivos que já são executáveis.

chmod -R u=rwX,go=rX /srv/site

O comando chown: alterar dono e grupo

Só o root pode trocar o dono de um arquivo, por isso o chown quase sempre é executado com sudo.

sudo chown alice report.txt               # dono
sudo chown alice:developers report.txt    # dono e grupo
sudo chown :www-data index.html           # apenas o grupo
sudo chown -R www-data:www-data /var/www/site

Para alterar só o grupo existe o comando chgrp: sudo chgrp developers report.txt. Os seus grupos são mostrados por id ou groups.

$ id
uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo),1001(developers)

Para adicionar um usuário a um grupo use sudo usermod -aG developers bob. A opção -a é obrigatória: sem ela, o usuário sai de todos os outros grupos secundários. O novo grupo passa a valer depois de um novo login.

sudo: executar ações como administrador

O sudo executa um único comando com privilégios de root (ou de outro usuário) e pede a sua senha, não a do root. Todas as chamadas são registradas em log, então se sabe quem fez o quê.

sudo apt update
sudo systemctl restart nginx
sudo -u postgres psql       # como o usuário postgres
sudo -i                     # shell interativo de root
sudo -l                     # o que eu tenho permissão de executar

Quem pode fazer o quê é definido em /etc/sudoers e nos arquivos do diretório /etc/sudoers.d/. Edite esses arquivos somente com sudo visudo: ele verifica a sintaxe, e um erro no arquivo não faz você perder o acesso ao sudo. No Ubuntu, o direito de usar sudo é dado pela participação no grupo sudo; nos sistemas da família RHEL, pelo grupo wheel.

# /etc/sudoers.d/deploy — o usuário deploy pode apenas reiniciar o nginx
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

Por que sudo echo > arquivo não funciona

Esta é uma armadilha comum:

$ sudo echo "127.0.0.1 test.local" >> /etc/hosts
bash: /etc/hosts: Permission denied

O redirecionamento >> é feito pelo seu shell, e não pelo sudo, então o arquivo é aberto sem privilégios de root. O certo é usar tee:

echo "127.0.0.1 test.local" | sudo tee -a /etc/hosts

Permission denied: causas e como corrigir

O erro Permission denied significa que o kernel recusou a operação ao seu processo. O diagnóstico segue sempre o mesmo roteiro: quem sou eu (id), quem é o dono e quais são as permissões (ls -l), quais são as permissões de cada diretório do caminho (namei -l).

$ namei -l /srv/app/config/app.env
f: /srv/app/config/app.env
drwxr-xr-x root  root  /
drwxr-xr-x root  root  srv
drwxr-x--- deploy deploy app
drwxr-xr-x deploy deploy config
-rw-r----- deploy deploy app.env

Aqui se vê que o diretório app está fechado para os demais: um usuário que não pertence ao grupo deploy não consegue passar por ele, independentemente das permissões do próprio arquivo.

O script não executa

$ ./deploy.sh
bash: ./deploy.sh: Permission denied

O arquivo não tem permissão de execução. A solução é chmod +x deploy.sh, ou executar pelo interpretador: bash deploy.sh. Se a partição estiver montada com a opção noexec (o que é comum em /tmp), não será possível executar o arquivo diretamente, e só a segunda opção funciona.

Não é possível gravar em um diretório do sistema

Os arquivos em /etc, /usr e /var/www pertencem ao root ou a usuários do sistema. Use sudo para alterações pontuais; para o trabalho contínuo, dê a permissão a um grupo, e não a todos.

O servidor web responde 403

O Nginx ou o Apache rodam com o usuário www-data (no Debian e no Ubuntu). Esse usuário precisa de leitura nos arquivos e de x em todos os diretórios do caminho. A correção: sudo chown -R www-data:www-data /var/www/site, ou permissões 755 para os diretórios e 644 para os arquivos.

O SSH não aceita a chave

O SSH recusa chaves com permissões excessivamente abertas. A chave privada deve ser 600, o diretório ~/.ssh deve ser 700, e o arquivo authorized_keys no servidor deve ser 600.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

Sem acesso ao Docker

A mensagem permission denied while trying to connect to the Docker daemon socket indica que você não está no grupo docker. Execute sudo usermod -aG docker $USER e entre no sistema novamente. Lembre que ser membro desse grupo equivale, na prática, a ter privilégios de root.

Por que chmod 777 é uma má ideia

O conselho «basta fazer chmod 777» elimina o erro, mas deixa o arquivo gravável por qualquer usuário e qualquer processo do sistema. Se uma aplicação web for invadida, o atacante poderá alterar esses arquivos. O caminho correto é descobrir qual usuário precisa de acesso e liberar a permissão exatamente para ele, pelo dono ou pelo grupo.

umask: permissões padrão

Os arquivos novos recebem permissões de acordo com a máscara umask. Com o valor comum 022, os arquivos são criados com 644 e os diretórios com 755.

$ umask
0022

Conclusão

As permissões no Linux são três conjuntos rwx para o dono, o grupo e os demais. O chmod altera as permissões no modo numérico (755, 644, 600) ou simbólico, o chown altera o dono, e o sudo permite executar um comando isolado como root. Diante de um Permission denied, verifique o usuário, as permissões do arquivo e as de cada diretório do caminho, e não resolva com 777. Usuários, grupos, permissões e sudo são explicados em detalhes e com prática no curso de Linux.