chmod vs chown vs sudo - Quando Usar Cada Um no Linux

2025-01-11 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediário+

Após dominar os fundamentos de gerenciamento de permissões, é hora de desenvolver "a capacidade de tomar decisões situacionais." chmod, chown e sudo são ferramentas poderosas, mas usá-las na ordem errada ou com julgamento inadequado pode levar a problemas sérios.

Termos usados neste artigo (definidos antes de começar)

• Permissão: a configuração que define quem pode ler, escrever ou executar um arquivo. Também chamada de "direito de acesso"
• owner / group / other: as três classes a que uma permissão se aplica: o usuário dono, os membros do grupo dono e todos os demais. No chmod são escritas u / g / o
• r / w / x: leitura (read), escrita (write) e execução (execute). Em um diretório, o x tem outro significado (visto adiante)
• Notação simbólica e notação numérica: chmod u+w é simbólica. chmod 644 é numérica, também chamada de octal
• umask: o valor subtraído das permissões dos arquivos recem-criados
• root: a conta de administrador que pode tudo. sudo significa "executar apenas este comando como root"

O Framework de Decisão (TL;DR)

Quando você encontrar um problema de permissão, siga esta ordem — nunca desvie.

1. Verifique proprietário, grupo e permissões com ls -l
2. Determine se você é o proprietário / grupo / outro
3. Escolha sua correção:
   • Adicionar permissões --> chmod
   • Mudar proprietário --> chown
   • Bypass temporário --> sudo (último recurso)

Usando chmod com Julgamento

Conclusão: Prefira notação simbólica; use numérica apenas quando puder explicar 644 ou 755.

Comece com Notação Simbólica (Segurança em Primeiro Lugar)

$ chmod u+w report.txt

-rw-r--r-- 1 user user 2048 report.txt

• Adiciona permissão de escrita (w) ao proprietário (u)
• Muda exatamente um ponto. O escopo de impacto é limitado, e por isso é menos propenso a acidentes

Por Que é Seguro

• O alvo (u/g/o) é especificado explicitamente
• Menos provável de sobrescrever permissões existentes

Exemplo Perigoso: Notação Numérica Descuidada

$ chmod 777 report.txt

O Problema

• Dá a todos, inclusive ao other, permissões de leitura, escrita e execução
• Qualquer pessoa que entre no mesmo servidor pode reescrever o conteúdo
• Isso leva a modificações não intencionais ou a executar um script que alguém substituiu

Por Que chmod 777 é Perigoso? (Aprofundamento)

777 = Qualquer Um Pode Fazer Qualquer Coisa

• Concede leitura + escrita + execução a todos
• Em servidores compartilhados, outros usuários poderiam injetar código malicioso

Incidente Real

Um caso em que /var/www foi definido como 777 em um servidor de produção:

• Atacante modificou arquivos PHP
• Instalou uma web shell (ferramenta de controle remoto)
• O servidor inteiro foi comprometido

Alternativas Seguras

• Diretórios: 755 (proprietário escreve, outros leem/executam)
• Arquivos: 644 (proprietário escreve, outros apenas leem)
• Se o servidor web precisa escrever em algum lugar, iguale o grupo dono e libere apenas isso com chmod g+w

Quando bater a tentação de usar 777

O 777 não elimina o problema de permissão. Ele elimina a verificação de permissão. Rode ls -l e id antes para saber se você é owner, group ou other. A correção certa é adicionar apenas o bit de que a parte correta realmente precisa.

umask: O Que Determina as Permissões Padrão de Arquivo

Por Que Novos Arquivos São Criados com 644?

umask "subtrai" permissões do padrão.

$ umask

0022

Como pensar: máscara, não subtração

O umask remove os bits de permissão indicados. Não é uma subtração aritmética. Com 022 o resultado coincide com a subtração, mas com outros valores não.

Calcular umask 077 como "666 - 077" não funciona por causa do empresta um. Entenda como retirar os bits indicados, e não como subtrair dígito a dígito.

Figura 1: umask 022 retira apenas os bits w de group e other. O que sobra vira 644, a permissão de um arquivo novo. As linhas não estão sendo subtraídas — as posições indicadas são simplesmente apagadas (este é o caso de arquivos; diretórios partem de 777 e chegam a 755).

Casos de Uso Práticos

• Permitir escrita do grupo em diretórios compartilhados --> umask 002
• Restringir outros de leitura por segurança --> umask 077

Armadilhas de Permissão de Diretório (Erro Avançado Mais Comum)

Conclusão: x no diretório permite entrar; sem x bloqueia cd — adicione apenas o mínimo necessário.

dr--r--r-- 2 user user 4096 logs/

Sintoma

• ls logs funciona (você consegue ler os nomes que estão dentro)
• ls -l logs mostra os nomes, mas exibe ? no tamanho e na data, porque não consegue consultar os arquivos de dentro
• cd logs falha com Permission denied

Razão

• Em um diretório, x significa "permissão para entrar". É um sentido diferente do x (execução) em um arquivo
• Em um diretório, r significa "permissão para listar os nomes de dentro". Só com r você não consegue nem entrar com cd nem abrir os arquivos

Solução

$ chmod u+x logs

chown: Mudança de Proprietário Como Último Recurso

Conclusão: Use chown apenas quando a propriedade está claramente errada; -R pode quebrar contas de serviço.

Quando Usar

$ sudo chown user:user app.log

Use somente quando a propriedade está claramente errada.

Um Desastre Comum

$ sudo chown -R user:user /var/www

O Que Acontece

• O servidor web roda com uma conta dedicada, como www-data
• Essa conta deixa de conseguir ler os arquivos
• Como consequência, o servidor web para de responder

Faça isto antes de executar

1. Anote o dono atual com ls -ld <diretorio alvo>
2. Tire o -R e teste primeiro com um único arquivo
3. Liste antes o que será alterado, por exemplo find /var/www ! -user www-data | head

O Desastre do chown -R (Com Passos de Recuperação)

O Que Realmente Aconteceu

Alguém executou chown -R myuser em /var/www:

• Apache/Nginx executa como www-data
• Arquivos de configuração e logs ficaram inacessíveis
• O serviço web caiu completamente

Passos de Recuperação

# Restaurar propriedade do conteudo web
$ sudo chown -R www-data:www-data /var/www/html

# Verificar propriedade
$ ls -la /var/www/html/

Lições Aprendidas

• -R (recursivo) tem um raio de explosão massivo
• Sempre verifique alvos com ls -la antes de executar
• Tenha cuidado extra com diretórios de serviço

sudo Não é Mágica

Conclusão: sudo é um bypass temporário; correções permanentes usam chmod ou chown, não cadeias de sudo.

$ sudo rm important.txt

• Conseguir executar e estar certo são coisas diferentes
• O sudo não elimina a causa. Ele apenas a esconde

A Mentalidade Correta

• O sudo é um bypass temporário
• A correção permanente é feita com chmod ou chown
• Antes de digitar sudo, verifique se consegue dizer em uma frase por que suas próprias permissões não bastam

A Espiral do sudo: Ponto Sem Retorno

Padrão Comum

1. Permission denied aparece
2. "Só dar sudo" e seguir em frente
3. Arquivo criado agora pertence ao root
4. Não consegue editá-lo como seu usuário
5. "sudo de novo" para editar...
6. Antes que perceba, tudo pertence ao root

Figura 2: um arquivo criado pelo sudo pertence ao root. Sua próxima edição é recusada, então esse mesmo usuário recorre de novo ao sudo. Esse ciclo é o que mantém vivo o "na dúvida, sudo".

Exemplo Real

# Crie um arquivo novo com sudo...
$ sudo vim new-config.yaml

# e ele pertence ao root
$ ls -l new-config.yaml
-rw-r--r-- 1 root root 1024 new-config.yaml

# Agora voce nao consegue edita-lo com seu usuario
$ vim new-config.yaml
# Permission denied...

Editar com sudo vim um arquivo existente que já é seu não muda o dono: o vim restaura o dono original ao gravar. Os arquivos de dono root se acumulam quando um comando executado com sudo cria um arquivo. sudo touch, sudo cp e um redirecionamento como sudo comando > arquivo criam arquivos de dono root pelo mesmo motivo.

A Abordagem Correta

• Antes de usar sudo, pergunte "por que não tenho permissão?"
• Edite arquivos de sistema com sudoedit (sudo -e). O arquivo mantém o dono original
• Depois, confira o dono com ls -l. Se algum arquivo ficou com dono root, restaure com sudo chown $USER <arquivo>

Alternativa: Design Sem Dores de Cabeça de Propriedade

Prevenindo Problemas de Permissão em Primeiro Lugar

1. Alinhar o Usuário de Execução

Configure sua aplicação para escrever em diretórios pertencentes ao usuário que a executa.

2. Resolver com Permissões de Grupo

# Criar grupo de desenvolvedores
$ sudo groupadd developers

# Adicionar usuarios ao grupo
$ sudo usermod -a -G developers user

# Alterar grupo do diretorio
$ sudo chgrp developers /path/to/project
$ sudo chmod g+w /path/to/project

Um grupo adicionado com usermod não vale para a sessão já aberta. Saia e entre de novo e confirme com groups.

3. Configurar a Aplicação

Aponte a saída de log e os arquivos temporários para um lugar onde o usuário que executa a aplicação possa escrever. Quanto mais próximos dos diretórios desse usuário, menos problemas de permissão aparecem.

Triagem de Mensagens de Erro (Exemplos Concretos)

Conclusão: Em Permission denied, verifique ls -l para encontrar proprietário e permissões, depois corrija.

Caso 1: Permission denied

$ echo test > report.txt

Permission denied

Passos de Investigação

$ ls -l report.txt

-r--r--r-- 1 user user 2048 report.txt

Decisão

• Se você é o proprietário --> chmod u+w resolve
• Se o proprietário é outro --> procure primeiro uma solução por grupo. Considere chown ou sudo apenas quando isso não bastar

Caso 2: Operation not permitted

$ chown user:user system.conf

Operation not permitted

Causa

• Mudar o dono exige root. Um usuário comum não consegue entregar a outra pessoa nem um arquivo próprio

Decisão

• Você realmente precisa mudar a propriedade?
• Consegue articular por que sudo é necessário?

Caso de Desastre: chmod -R que Deu Errado

O Pior Cenário

# Definindo diretorio inteiro como 777...
$ chmod -R 777 .

O Que Acontece

• Alcança tudo abaixo do diretório atual, inclusive os ocultos como .git e .ssh
• Todos os arquivos de todos os subdiretórios ficam graváveis por qualquer um
• Se o ~/.ssh estiver no escopo, o SSH recusa chaves com permissões frouxas e o login por chave para de funcionar

Prevenção

• Sempre inspecione os alvos com ls -la antes de usar -R
• Primeiro execute sem -R em um único arquivo ou diretório
• Verifique o resultado, depois expanda o escopo
• Arquivos e diretórios precisam de bits diferentes. Não defina os dois juntos: use find . -type f -exec chmod 644 {} + e find . -type d -exec chmod 755 {} +

Exercício Prático (10 min)

Conclusão: Experimente um erro de permissão, leia a saída do ls -l e escolha a correção certa.

Execute os seguintes comandos para experimentar um erro de permissão em primeira mão. Eles criam um diretório de trabalho novo, então nada existente é afetado.

$ mkdir perm-adv
$ cd perm-adv
$ touch test.txt
$ chmod u-w test.txt
$ echo test > test.txt

Pontos de Verificação

1. Você recebeu Permission denied?
2. Consegue explicar por que olhando o ls -l?
3. Consegue determinar qual comando vai corrigir?

Próximas Leituras

Conclusão: Próximo: pratique operações de permissão com segurança no terminal virtual.

Aplique o "framework de decisão" que você aprendeu neste artigo em um terminal real. Penguin Gym Linux oferece um ambiente virtual seguro onde você pode praticar operações de permissão sem risco.

• Permissões (Prático) - Solução de Problemas
• Permissões (Básico) - Fundamentos de chmod, ls -l
• Comandos Básicos