Como Usar chmod e chown - Guia de Permissões de Arquivos no Linux

2025-01-11 Tempo de leitura: Cerca de 12 min Dificuldade: Beginner

O que você vai aprender:

• Diagnosticar problemas lendo a saída do ls -l
• Escolher entre chmod / chown e aplicar a correção certa
• Largar o hábito de usar "sudo para tudo" cegamente

Público-alvo: Iniciantes começando a trabalhar com servidores Ubuntu

Nota: Algumas operações exigem sudo

Fluxo de Decisão (Referência Rápida)

Conclusão: No Permission denied, verifique o ls -l e escolha chmod, chown ou sudo conforme o caso.

Quando você encontrar "Permission denied", consulte esta tabela de cima para baixo.

Primeiro, Aprenda a Ler o ls -l (O Mais Importante)

Conclusão: 90% dos problemas de permissão mostram sua causa no ls -l — aprenda a lê-lo primeiro.

90% dos problemas de permissão podem ser diagnosticados com ls -l. Quando você souber ler isso, poderá largar o "uso cego do sudo".

$ ls -l sample.txt

-rw-r--r-- 1 user user  1234 Dec 17 12:00 sample.txt

Por que esta ordem?: Erros de permissão dizem respeito à combinação de "quem" pode fazer "o quê". Seguir esta ordem permite diagnosticar a causa de forma lógica.

Entenda o rwx como "Critério de Decisão"

Conclusão: Leia as permissões de proprietário/grupo/outros para determinar o que cada papel pode fazer.

Exemplo: rw-r--r--

chmod: Comece com a Notação Simbólica (Prevenção de Acidentes)

Conclusão: Use a notação simbólica como u+w por padrão; numérica só quando puder explicá-la.

Uso Básico

$ chmod u+w sample.txt

Significado:

• u (owner / proprietário)
• w (write / escrita)
• Adicionar permissão

Por que a notação simbólica é mais segura: Ela mostra claramente "o que mudou". chmod u+w é mais explícito que chmod 644, facilitando detectar erros durante a revisão de código.

$ chmod 777 sample.txt

Por que chmod 777 é perigoso?

777 significa "qualquer um pode ler, escrever e executar".

Incidente do Mundo Real

Um servidor web em produção tinha /var/www/html configurado como chmod -R 777. Resultado:

• Um atacante enviou um arquivo PHP
• Esse PHP foi executado, comprometendo o servidor
• Dados de clientes vazaram, o serviço caiu

Por Que o Ataque Teve Sucesso

777 = dar w (escrita) e x (execução) a other (todos). Arquivos podiam ser colocados pelo servidor web e executados.

Alternativas Seguras

Como ler a notação numérica: r=4, w=2, x=1 somados. Por exemplo, 755 = rwx(7) + r-x(5) + r-x(5) = o proprietário tem todas as permissões, grupo e outros só podem ler e executar.

Cuidado com a Permissão de Execução em Diretórios

Conclusão: O x em diretório significa permissão de entrada; sem x o cd é bloqueado — adicione só o mínimo.

drwxr-xr-x 2 user user 4096 Dec 17 12:10 mydir

• O x do diretório: determina se você pode entrar (se consegue fazer cd nele)
• Apenas r não basta para o cd (você vê a lista de arquivos mas não consegue entrar)

chown: Mude a Propriedade com Cuidado

Conclusão: Mude a propriedade só quando claramente necessário; -R pode quebrar contas de serviço.

Uso Básico

$ sudo chown user:user sample.txt

Por que o sudo é necessário: Mudar a propriedade é uma operação de administração do sistema. Seria perigoso se qualquer usuário pudesse reivindicar a propriedade dos arquivos de outros.

Como o chown -R quebrou a produção (com recuperação)

O Que Aconteceu

$ sudo chown -R myuser:myuser /var/www/html

Quis "editar meus próprios arquivos". Resultado:

• Apache/Nginx roda como usuário www-data
• Após mudar a propriedade, o servidor web não conseguia ler os arquivos
• O site exibiu 403 Forbidden

Recuperação

$ sudo chown -R www-data:www-data /var/www/html

Abordagem Correta

Se você quer editar arquivos, em vez de mudar a propriedade:

• Adicione-se ao grupo www-data
• Ou use sudo -u www-data vim file.php para editar

sudo Não é Mágica

Conclusão: sudo mascara a causa raiz; diagnostique com ls -l primeiro e use sudo só se necessário.

• sudo = simplesmente executa como root
• Pode mascarar problemas subjacentes no design das permissões

$ sudo chmod 777 ...

Incidentes reais por abuso de sudo

Padrão de Incidente 1: Não consegue mais editar o arquivo

$ sudo vim config.yaml

Depois, ao tentar editar normalmente com vim config.yaml:

E45: 'readonly' option is set (add ! to override)

Causa: Abrir com sudo deixou o arquivo com propriedade do root (ou o arquivo .swp foi criado como root)

Solução

• sudo chown $USER:$USER config.yaml para restaurar a propriedade
• Ou use sudoedit config.yaml (sudo -e) desde o início

Padrão de Incidente 2: O diretório home fica com propriedade do root

$ sudo chown -R root:root ~

Resultado: Não consegue logar, .bashrc ilegível, chaves SSH não funcionam.

Recuperação: A partir de outra sessão root: chown -R user:user /home/user

Solução de Problemas Comuns de Permission Denied

Conclusão: Verifique o ls -l para identificar seu papel e a propriedade, depois aplique a correção certa.

Caso 1: Não Consegue Escrever no Arquivo

$ echo "test" >> /etc/hosts

-bash: /etc/hosts: Permission denied

Diagnóstico

$ ls -l /etc/hosts

-rw-r--r-- 1 root root 221 Dec 17 10:00 /etc/hosts

Causa

• O proprietário é root
• Você está na posição other → r-- (somente leitura)

Equívoco Comum

"Basta usar sudo" → Meio certo, meio errado

/etc/hosts é um arquivo de sistema, intencionalmente gravável apenas pelo root. Usar sudo para editar está correto, mas entenda "por que ele é protegido" antes de fazê-lo.

Caso 2: Não Consegue Executar o Script

$ ./deploy.sh

-bash: ./deploy.sh: Permission denied

Diagnóstico

$ ls -l deploy.sh

-rw-r--r-- 1 user user 1234 Dec 17 11:00 deploy.sh

Causa

• As permissões são rw-r--r-- → sem permissão de execução (x)
• Você é o proprietário mas ainda assim não consegue executar

Correção

$ chmod u+x deploy.sh
$ ./deploy.sh

Por que isso é seguro: u+x concede a permissão de execução apenas ao proprietário. Não afeta outros usuários, então é uma mudança mínima.

Caso 3: Não Consegue Entrar no Diretório

$ cd /var/log/nginx

-bash: cd: /var/log/nginx: Permission denied

Diagnóstico

$ ls -ld /var/log/nginx

drwxr-x--- 2 www-data adm 4096 Dec 17 10:00 /var/log/nginx

Causa

• As permissões são rwxr-x--- → nada permitido para other
• Você não é www-data nem está no grupo adm

Opções de Correção

1. sudo cd não funciona (cd é built-in do shell) → Use sudo ls /var/log/nginx para ver o conteúdo
2. Adicione-se ao grupo adm: sudo usermod -aG adm $USER (exige novo login — as informações de grupo são carregadas no momento do login)

Checklist de Diagnóstico de Permissões

Conclusão: Confirme sua identidade com whoami e groups, depois verifique o ls -l para escolher a correção certa.

Quando você encontrar "Permission denied", verifique o seguinte em ordem.

Passo 1: Verifique Sua Identidade

• Verificou seu nome de usuário com whoami
• Verificou seus grupos com groups

Passo 2: Verifique o Estado do Arquivo/Diretório

• Verificou permissões e proprietário com ls -l arquivo
• Determinou se você é proprietário / grupo / outros
• Verificou se a permissão necessária (r/w/x) está concedida para sua posição

Passo 3: Escolha o Método de Resolução

• Permissão insuficiente → Adicione com chmod
• Proprietário diferente → Mude com chown (exige sudo)
• Arquivo de sistema → Use sudoedit ou sudo

Passo 4: Verifique as Mudanças

• Confirmou as mudanças com ls -l novamente
• Verificou que a operação pretendida tem sucesso
• Confirmou que nenhuma permissão excessiva (como 777) foi concedida

Exercício Prático (5 min)

Conclusão: Remova a permissão de escrita, encontre o erro e depois recupere para aprender a correção.

$ mkdir ~/perm-test
$ cd ~/perm-test
$ touch a.txt
$ ls -l
$ chmod u-w a.txt
$ echo "test" > a.txt

Resultado Esperado:

• Você recebe "Permission denied"
• Você consegue explicar pelo ls -l que "sou o proprietário mas falta a permissão w"

Recuperação:

$ chmod u+w a.txt
$ echo "test" > a.txt
$ cat a.txt

test