Guia de permissões Linux: erros fatais e como evitá-los

17 min de leitura  ·  Guia técnico

Permissões de arquivo no Linux controlam quem pode ler, gravar e executar cada arquivo ou diretório do sistema. Configurá-las incorretamente em um servidor web pode derrubar sites, expor dados sensíveis ou abrir brechas de segurança irreversíveis. Para corrigir ou auditar permissões com segurança, siga estes passos:

1. Verifique as permissões atuais com ls -la ou stat
2. Identifique o dono e grupo corretos com ls -la e ajuste com chown
3. Aplique permissões seguras para arquivos (chmod 644) e diretórios (chmod 755)
4. Use find para corrigir recursivamente sem misturar arquivos e diretórios
5. Proteja arquivos sensíveis como wp-config.php com chmod 600
6. Valide o resultado com ls -la e teste o acesso pelo servidor web

Pré-requisitos para gerenciar permissões de arquivo no Linux

• Acesso SSH ao servidor com usuário root ou com privilégios sudo — veja como acessar em Acessando servidores VPS Linux da AviraHost
• Sistema operacional Linux: Debian 12, Ubuntu 24.04 LTS, Rocky Linux 9 ou AlmaLinux 9
• Conhecimento básico de terminal e navegação por diretórios
• Servidor web instalado (Apache 2.4 ou Nginx 1.26) caso o objetivo seja corrigir erros 403
• Identificação do usuário que o servidor web utiliza — geralmente www-data no Debian/Ubuntu ou apache no Rocky/AlmaLinux

Como o sistema de permissões de arquivo no Linux funciona

O modelo de permissões do Linux é baseado em três entidades — dono, grupo e outros — e três ações possíveis: leitura (r=4), escrita (w=2) e execução (x=1). Cada arquivo e diretório possui exatamente um dono e um grupo associado. Ao executar ls -la, a string de permissões exibida segue o padrão:

-rwxr-xr--  1 deploy www-data 4096 Jun 10 14:22 index.php

Lendo da esquerda para a direita: o primeiro caractere indica o tipo (- para arquivo, d para diretório, l para link simbólico). Os nove caracteres seguintes são divididos em três grupos de três: permissões do dono, do grupo e de outros. No exemplo acima, o dono tem rwx (7), o grupo tem r-x (5) e outros têm r-- (4) — resultando no modo octal 754.

A notação octal é a forma mais prática de trabalhar com chmod. Cada dígito é a soma dos valores das permissões ativas: r=4, w=2, x=1. Assim, 7 = rwx, 6 = rw-, 5 = r-x, 4 = r--. Entender essa matemática evita a maioria dos erros fatais de configuração.

Diretórios exigem a permissão de execução para que possam ser acessados (navegados). Sem o bit x no diretório pai, nenhum arquivo dentro dele será acessível, mesmo que o arquivo em si tenha permissões corretas. Esse é um dos erros mais frequentes ao configurar o DocumentRoot do Apache ou o root do Nginx.

Verificando permissões de arquivos e diretórios no Linux

Antes de alterar qualquer coisa, auditar o estado atual é essencial. O comando ls -la exibe permissões, dono, grupo, tamanho e data de modificação de todos os itens de um diretório, incluindo arquivos ocultos.

ls -la /var/www/html/

total 48
drwxr-xr-x  5 root     www-data 4096 Jun 10 14:00 .
drwxr-xr-x  3 root     root     4096 Jun  1 09:15 ..
-rw-r--r--  1 deploy   www-data 1234 Jun 10 13:55 index.php
drwxr-xr-x  2 deploy   www-data 4096 Jun 10 12:00 wp-content
-rw-------  1 deploy   www-data  512 Jun  5 10:30 wp-config.php

Para inspecionar um único arquivo com detalhes completos, incluindo o modo octal, use stat:

stat /var/www/html/wp-config.php

  File: /var/www/html/wp-config.php
  Size: 512
Access: (0600/-rw-------)  Uid: (1001/deploy)   Gid: (33/www-data)
Modify: 2024-06-05 10:30:00.000000000 -0300

Para verificar recursivamente todos os arquivos de um diretório e identificar itens com permissões problemáticas, combine find com filtros de modo:

find /var/www/html -perm 777

Se este comando retornar qualquer resultado, você tem arquivos com permissão total aberta — uma vulnerabilidade crítica que precisa ser corrigida imediatamente.

Aplicando permissões corretas com chmod e chown

O controle de acesso a arquivos no Linux é exercido pelos comandos chmod (altera permissões) e chown (altera dono e grupo). Usá-los corretamente é a base de qualquer hardening de servidor web.

Para definir o dono e grupo de um diretório web inteiro:

chown -R deploy:www-data /var/www/html/

Substitua deploy pelo usuário que faz deploy da aplicação e www-data pelo usuário do servidor web. No Rocky Linux 9 e AlmaLinux 9, o grupo padrão do Apache é apache:

chown -R deploy:apache /var/www/html/

Atenção: o comando chown -R é recursivo e afeta todos os arquivos e subdiretórios. Confirme o caminho antes de executar para evitar alterar permissões em diretórios do sistema.

Para aplicar permissões seguras de forma recursiva, nunca use chmod -R 755 diretamente em um diretório web, pois isso tornará todos os arquivos executáveis — o que é desnecessário e inseguro. Use find para tratar arquivos e diretórios separadamente:

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

Após executar, verifique o resultado:

ls -la /var/www/html/

drwxr-xr-x  5 deploy www-data 4096 Jun 10 14:00 wp-content
-rw-r--r--  1 deploy www-data 1234 Jun 10 13:55 index.php

Para arquivos que contêm credenciais — como wp-config.php, arquivos .env ou chaves privadas — aplique permissão restrita:

chmod 600 /var/www/html/wp-config.php
chmod 600 /var/www/html/.env

Com 600, apenas o dono pode ler e gravar. O servidor web (rodando como www-data) ainda consegue ler o arquivo se for do mesmo grupo e a permissão de grupo for pelo menos r-- (modo 640). Avalie qual se aplica ao seu ambiente.

Erros fatais de permissão e seus impactos reais

A má configuração de permissões de arquivo é uma das causas mais comuns de incidentes de segurança e indisponibilidade em servidores Linux. Conhecer os erros mais frequentes permite evitá-los antes que causem dano.

• chmod 777 em arquivos web: concede leitura, escrita e execução a qualquer usuário do sistema. Em hospedagem compartilhada, outros usuários podem modificar ou injetar código nos seus arquivos. Em VPS, processos comprometidos ganham acesso total.
• chmod -R 755 em arquivos de configuração: torna arquivos como wp-config.php e .htpasswd executáveis e legíveis por todos os usuários do sistema — expondo credenciais de banco de dados.
• Dono incorreto no DocumentRoot: se o dono dos arquivos não for o usuário do servidor web nem pertencer ao grupo correto, o Apache ou Nginx retornará erro 403 mesmo com permissões aparentemente corretas.
• Bit de execução ausente em diretórios: um diretório com chmod 644 (sem o bit x) impede que qualquer usuário — incluindo o servidor web — navegue por ele, causando erro 403 ou 500.
• Permissões muito restritivas em scripts CGI ou PHP-FPM: scripts que precisam ser executados pelo servidor web requerem o bit x para o usuário ou grupo correto. Sem ele, o servidor retorna erro 500.
• Ignorar permissões de links simbólicos: links simbólicos herdam as permissões do arquivo de destino, não do link em si. Um link apontando para um arquivo com chmod 777 é tão perigoso quanto o arquivo original.

Para uma visão mais ampla sobre boas práticas de configuração de servidores, consulte as Dicas de Otimização de Servidores Linux da AviraHost.

Permissões especiais: SUID, SGID e Sticky Bit

Além das permissões básicas, o Linux possui três bits especiais que afetam o comportamento de execução e acesso — e que, se mal configurados, representam vetores de escalada de privilégios.

SUID (Set User ID — modo 4xxx): quando aplicado a um executável, faz com que ele rode com as permissões do dono do arquivo, não do usuário que o executa. O comando passwd usa SUID para permitir que usuários comuns alterem sua própria senha (que é armazenada em arquivos de propriedade do root). Nunca aplique SUID a scripts interpretados (shell, Python, PHP) — isso cria uma vulnerabilidade crítica.

chmod u+s /usr/bin/meu-executavel

SGID (Set Group ID — modo 2xxx): em executáveis, funciona como o SUID mas para o grupo. Em diretórios, faz com que novos arquivos criados dentro herdem o grupo do diretório pai — muito útil em ambientes colaborativos ou de deploy.

chmod g+s /var/www/html/uploads/

Sticky Bit (modo 1xxx): em diretórios, impede que usuários deletem arquivos de outros usuários, mesmo tendo permissão de escrita no diretório. O diretório /tmp usa sticky bit por padrão. Em servidores web, é útil em diretórios de upload compartilhados.

chmod +t /var/www/html/uploads/

Para identificar arquivos com SUID ou SGID no sistema — o que pode indicar uma configuração insegura ou comprometimento:

find / -perm /6000 -type f 2>/dev/null

Atenção: revise cuidadosamente qualquer resultado inesperado. Arquivos com SUID fora de /usr/bin e /usr/sbin são suspeitos e devem ser investigados.

Permissões seguras para WordPress no Linux

O WordPress é um dos alvos mais comuns de exploração via permissões incorretas. A configuração recomendada equilibra funcionalidade e segurança, permitindo que o servidor web leia os arquivos sem conceder acesso de escrita desnecessário.

Estrutura de permissões recomendada para uma instalação WordPress em /var/www/html/:

• Diretórios: 755 — dono lê/escreve/executa; grupo e outros leem e executam
• Arquivos PHP e HTML: 644 — dono lê/escreve; grupo e outros apenas leem
• wp-config.php: 600 ou 640 — apenas dono (ou dono + grupo) pode ler
• Diretório wp-content/uploads/: 755 com dono www-data para permitir uploads
• .htaccess: 644 — o WordPress precisa reescrever este arquivo para permalinks

Script completo para corrigir permissões de uma instalação WordPress:

WP_PATH="/var/www/html"
WEB_USER="www-data"

chown -R deploy:${WEB_USER} ${WP_PATH}
find ${WP_PATH} -type d -exec chmod 755 {} \;
find ${WP_PATH} -type f -exec chmod 644 {} \;
chmod 600 ${WP_PATH}/wp-config.php
chown ${WEB_USER}:${WEB_USER} ${WP_PATH}/wp-content/uploads/

Se você gerencia o WordPress via FTP, o artigo Como usar o Filezilla como software FTP da minha Hospedagem explica como verificar e alterar permissões diretamente pelo cliente FTP, sem precisar de acesso SSH.

Problemas comuns e como resolver

Sintoma: Erro 403 Forbidden após alterar permissões

Causa: o servidor web não tem permissão de leitura sobre o arquivo ou de execução (navegação) sobre o diretório pai. Isso ocorre quando chmod 600 ou chmod 700 é aplicado a arquivos públicos ou ao próprio DocumentRoot.
Solução: verifique as permissões com ls -la /var/www/html/ e corrija com chmod 644 para arquivos e chmod 755 para diretórios. Confirme também que o dono ou grupo do arquivo inclui o usuário do servidor web (www-data ou apache). Reinicie o servidor web após a correção: systemctl restart apache2 ou systemctl restart nginx.

Sintoma: Erro 500 Internal Server Error em scripts PHP

Causa: o arquivo PHP tem permissão de execução (chmod 755 ou 777) quando o servidor usa PHP-FPM ou mod_php — nesses casos, o bit de execução não é necessário e pode causar conflito com configurações de segurança do servidor. Alternativamente, o arquivo pode ter permissões muito restritivas impedindo a leitura.
Solução: aplique chmod 644 em todos os arquivos .php. Verifique os logs de erro do servidor: tail -f /var/log/apache2/error.log ou tail -f /var/log/nginx/error.log para identificar o arquivo específico que está causando o problema.

Sintoma: WordPress não consegue fazer upload de imagens

Causa: o diretório wp-content/uploads/ não pertence ao usuário do servidor web ou não tem permissão de escrita para ele. O WordPress precisa criar subdiretórios por ano/mês e gravar arquivos nesse caminho.
Solução: execute chown -R www-data:www-data /var/www/html/wp-content/uploads/ e confirme que o diretório tem chmod 755. Se o diretório não existir, crie-o: mkdir -p /var/www/html/wp-content/uploads && chown www-data:www-data /var/www/html/wp-content/uploads.

Sintoma: Arquivos criados por deploy têm permissões erradas automaticamente

Causa: o umask do usuário de deploy está configurado de forma inadequada, fazendo com que novos arquivos sejam criados com permissões mais abertas ou mais restritivas do que o desejado.
Solução: verifique o umask atual com o comando umask. O valor recomendado para ambientes web é 0022 (resulta em 644 para arquivos e 755 para diretórios). Para definir permanentemente, adicione umask 0022 ao arquivo ~/.bashrc ou /etc/profile do usuário de deploy. Alternativamente, aplique SGID no diretório web para que novos arquivos herdem o grupo correto.

Sintoma: find retorna arquivos com chmod 777 após atualização do CMS

Causa: alguns plugins ou scripts de instalação de CMS aplicam chmod 777 em diretórios de cache ou upload para garantir compatibilidade máxima, sem considerar o ambiente de segurança.
Solução: execute o comando de auditoria find /var/www/html -perm 777 regularmente. Corrija imediatamente com find /var/www/html -perm 777 -type f -exec chmod 644 {} \; e find /var/www/html -perm 777 -type d -exec chmod 755 {} \;. Considere adicionar essa verificação a um script de monitoramento periódico via cron.

Perguntas frequentes sobre permissões de arquivo no Linux

Qual a diferença entre chmod 755 e chmod 644 no Linux?

chmod 755 concede ao dono leitura, escrita e execução; ao grupo e outros, apenas leitura e execução — ideal para diretórios e scripts executáveis. chmod 644 concede ao dono leitura e escrita; ao grupo e outros, apenas leitura — padrão seguro para arquivos de configuração e páginas web. Usar 755 em arquivos de configuração sensíveis é um erro de segurança grave, pois qualquer usuário do sistema pode executar o arquivo.

Por que meu site retorna erro 403 Forbidden após alterar permissões?

O erro 403 ocorre quando o servidor web (Apache ou Nginx) não tem permissão de leitura sobre o arquivo ou execução sobre o diretório pai. A causa mais comum é aplicar chmod 600 ou chmod 700 em arquivos públicos ou diretórios do DocumentRoot. Corrija com chmod 644 para arquivos e chmod 755 para diretórios, verificando também o dono com ls -la para garantir que o usuário do servidor web tem acesso.

Como verificar as permissões de um arquivo ou diretório no Linux?

Execute ls -la /caminho/do/arquivo para listar permissões, dono e grupo. A saída exibe uma string como -rw-r--r-- seguida do usuário e grupo. Para verificar recursivamente um diretório inteiro, use ls -laR /caminho/ ou stat /caminho/arquivo para detalhes completos incluindo permissões em formato octal — o que facilita a comparação com os valores esperados.

É seguro usar chmod 777 em arquivos do WordPress?

Não. chmod 777 concede permissão total de leitura, escrita e execução a qualquer usuário do sistema, incluindo processos maliciosos. Em ambientes de hospedagem compartilhada, isso permite que outros usuários modifiquem ou executem seus arquivos. O padrão seguro para WordPress é 644 para arquivos e 755 para diretórios, com wp-config.php em 600 ou 640 — nunca use 777 em produção.

Como corrigir permissões de forma recursiva sem afetar arquivos e diretórios de forma diferente?

Use find combinado com chmod para aplicar permissões distintas a arquivos e diretórios separadamente. Para diretórios: find /var/www/html -type d -exec chmod 755 {} \;. Para arquivos: find /var/www/html -type f -exec chmod 644 {} \;. Esse método evita o erro comum de aplicar chmod -R 755 que torna todos os arquivos executáveis desnecessariamente, criando riscos de segurança.

Conclusão

• Audite regularmente: execute find /var/www/html -perm 777 periodicamente e adicione essa verificação ao seu processo de deploy para detectar permissões inseguras antes que sejam exploradas.
• Separe sempre arquivos de diretórios: use find -type f e find -type d com chmod para aplicar 644 em arquivos e 755 em diretórios — nunca use chmod -R sem essa distinção.
• Proteja credenciais com rigor: arquivos como wp-config.php, .env e chaves privadas devem ter no máximo chmod 640, com dono correto e grupo restrito ao servidor web — nunca 644 ou mais aberto.

Leia também

• Checklist Completo para Configurar e Testar o Firewall UFW em VPS Linux e Servidores Dedicados
• Guia Prático para Ativar e Gerenciar o SSH Key Authentication em VPS Linux e Servidores Dedicados
• Como Instalar e Configurar o OpenVPN no VPS Linux para Acesso Seguro Remoto

Precisa de ajuda com permissões e segurança no seu servidor Linux?

Configurar permissões corretamente é fundamental para manter seu servidor seguro e seus sites funcionando. Um VPS Linux com suporte especializado pode fazer toda a diferença na hora de diagnosticar e corrigir problemas de acesso.

Conheça os planos de VPS Linux da AviraHost