Permissões e usuários no Linux sem mistério

Permissões no Linux assustam no começo, mas seguem uma lógica simples e consistente. Cada arquivo tem um dono, um grupo e um conjunto de permissões para todos os outros. Entender essas três camadas resolve praticamente tudo — e evita o hábito perigoso de dar permissão total para "fazer funcionar".

Lendo as permissões

Ao rodar ls -l, você vê algo como:

-rwxr-xr--  1 triat  desenvolvimento  4096 Ago 30 14:22 script.sh

Os dez primeiros caracteres contam a história inteira:

• o primeiro diz o tipo: - arquivo comum, d diretório, l link simbólico;
• os três seguintes (rwx) são do dono — aqui, o usuário triat pode ler, escrever e executar;
• os três do meio (r-x) são do grupo — quem estiver no grupo desenvolvimento pode ler e executar, mas não alterar;
• os três últimos (r--) são para todos os outros — só leitura.

Mudando com chmod

Há duas formas de escrever, e vale conhecer as duas:

# notação numérica
chmod 750 script.sh    # dono: tudo | grupo: ler+exec | outros: nada
chmod 640 config.yml   # dono: ler+escrever | grupo: ler | outros: nada

# notação simbólica — altera só o que você citar
chmod +x script.sh     # torna executável para todos
chmod g+w pasta/       # dá escrita ao grupo
chmod o-r arquivo      # tira leitura dos outros

Os números vêm da soma: leitura = 4, escrita = 2, execução = 1. Então 7 = rwx, 6 = rw-, 5 = r-x, 4 = r--, 0 = nada.

A notação simbólica é mais segura no dia a dia porque é cirúrgica: chmod +x não mexe nas outras permissões, enquanto chmod 755 reescreve tudo — inclusive o que você não queria alterar.

Permissão em diretório significa outra coisa

Este é o ponto que mais confunde. Em diretórios, as mesmas letras têm sentidos diferentes:

Duas consequências práticas surpreendem quem está começando. A primeira: sem x no diretório, você não acessa nada lá dentro, mesmo tendo permissão total nos arquivos. A segunda, mais séria: quem tem w em um diretório pode apagar arquivos dele mesmo sem ter permissão nenhuma sobre esses arquivos. A permissão de apagar é do diretório, não do arquivo.

Mudando o dono

sudo chown triat:desenvolvimento arquivo.txt
sudo chown -R www-data:www-data /var/www/site
sudo chgrp desenvolvimento relatorio.pdf

O -R aplica recursivamente. É útil e perigoso na mesma medida — conferir o caminho duas vezes antes de rodar é um hábito que economiza noites de trabalho.

Grupos: como se organiza acesso de verdade

Dar permissão usuário por usuário não escala. A forma correta é por grupo:

sudo groupadd financeiro
sudo usermod -aG financeiro maria
sudo chown -R :financeiro /dados/financeiro
sudo chmod -R 770 /dados/financeiro
groups maria                    # conferir a que grupos pertence

Uma observação prática: mudanças de grupo só valem a partir da próxima sessão. Se o usuário já estava logado, precisa sair e entrar de novo.

O bit SGID em diretórios compartilhados

Problema comum: uma pasta é compartilhada por um time, mas cada arquivo criado ali fica com o grupo pessoal de quem criou, e os colegas não conseguem editar. A solução é o SGID:

sudo chmod 2770 /dados/projetos

O 2 na frente faz todo arquivo criado dentro herdar o grupo do diretório, e não o do usuário. É o que faz uma pasta compartilhada funcionar de verdade.

Fuja do 777

Quando algo "só funciona com 777", o problema real é quase sempre de dono, não de permissão. O caminho certo é descobrir com qual usuário o serviço roda e ajustar a propriedade:

ps aux | grep nginx                        # descobrir o usuário do serviço
sudo chown -R www-data:www-data /var/www/site
sudo find /var/www/site -type d -exec chmod 750 {} \;
sudo find /var/www/site -type f -exec chmod 640 {} \;

Os dois últimos comandos aplicam permissões diferentes para diretórios e arquivos — diretórios precisam de x para serem atravessados; arquivos comuns não precisam ser executáveis.

sudo bem configurado

Dar sudo irrestrito a todo mundo é o equivalente a distribuir a senha de root. O sudo permite granularidade — configure com visudo, que valida a sintaxe antes de salvar:

# operador pode reiniciar serviços, e só isso
%operadores ALL=(root) /bin/systemctl restart nginx, /bin/systemctl status *

# analista pode ver logs sem alterar nada
%analistas ALL=(root) NOPASSWD: /usr/bin/journalctl

A regra de ouro

Conceda sempre a menor permissão que resolve. Um serviço web não precisa ser dono do sistema inteiro — precisa ler seus arquivos e escrever em sua pasta de dados. Um usuário do financeiro não precisa acessar a pasta de RH.

Na prática, três perguntas resolvem quase toda decisão: quem precisa ler? Quem precisa escrever? Existe alguma razão para mais alguém ter acesso? Se a resposta da terceira for "não", o resto se escreve sozinho.