Permissões de ficheiros do WordPress: 644, 755 e proprietário

Permissões de ficheiros do WordPress: a regra segura em poucas linhas

Para as permissões de ficheiros do WordPress, a regra segura é 755 para diretórios, 644 para ficheiros e um 640 ou 600, mais restritivo, para o wp-config.php. Nunca use 777. Estes números só o protegem, porém, se o utilizador certo for o proprietário dos ficheiros. Um 644 perfeito em ficheiros que pertencem à conta errada ou impede carregamentos e atualizações, ou dá discretamente ao servidor web mais poder do que precisa. Por isso, leia a secção sobre propriedade antes de alterar qualquer permissão.

Proprietário, grupo e outros: como ler 755 e 644

Execute ls -l na raiz do WordPress e vai ver linhas como estas:

drwxr-xr-x  5 deploy www-data  4096 Oct 30 09:12 wp-content
-rw-r--r--  1 deploy www-data   405 Oct 30 09:12 index.php
-rw-r-----  1 deploy www-data  3214 Oct 30 09:12 wp-config.php

O primeiro carácter indica o tipo (d para diretório, - para ficheiro). Seguem-se três grupos de três letras: um para o proprietário (deploy), um para o grupo (www-data) e um para todos os outros. r significa leitura, w escrita e x execução. Cada letra tem um valor: r = 4, w = 2, x = 1. Somados por grupo, dão o modo octal, pelo que rwxr-xr-x passa a 7-5-5.

Num diretório, x quer dizer «pode entrar». Sem ele, o PHP não consegue abrir os ficheiros lá dentro, mesmo que estes sejam legíveis. É por isso que os diretórios precisam de 755 e os ficheiros ficam bem com 644. Numa instalação normal do WordPress, nenhum ficheiro precisa do bit de execução.

A propriedade conta tanto como o modo

Primeiro, descubra com que utilizador o PHP corre. No seu próprio servidor, veja os processos em execução:

ps -eo user,comm | grep -E 'php-fpm|apache2|httpd' | sort | uniq

Com PHP-FPM, o processo principal corre como root e os processos de trabalho correm como o utilizador do pool. Essa definição está no ficheiro do pool, que em Debian e Ubuntu costuma ficar em /etc/php/<versão>/fpm/pool.d/:

grep -R -E '^(user|group) *=' /etc/php/*/fpm/pool.d/

A documentação de configuração do PHP-FPM descreve estas opções. Com Apache e mod_php, o PHP corre como o próprio utilizador do Apache: www-data em Debian/Ubuntu, apache em sistemas baseados em RHEL. Nesse caso, todos os sites do servidor partilham a mesma identidade. Um bom alojamento partilhado isola os sites: o PHP de cada conta corre com o utilizador dessa conta. Se não puder executar ps, consulte Ferramentas > Saúde do site > Informação > Permissões do sistema de ficheiros. Aí vê se o WordPress consegue escrever no diretório principal, em wp-content, nos carregamentos, nos plugins e nos temas.

Depois de saber qual é o utilizador do PHP, escolha um de dois modelos de propriedade.

Modelo A: o utilizador do PHP é proprietário de tudo. É o habitual em alojamento partilhado com isolamento, onde o utilizador da conta e o do PHP são o mesmo. As atualizações pelo painel, a instalação de plugins e os carregamentos funcionam. O senão é que qualquer código executado como PHP também pode reescrever todos os ficheiros, incluindo o núcleo, os plugins e o wp-config.php.

Modelo B: um utilizador de deploy é proprietário e o PHP só lê. Os ficheiros pertencem a algo como deploy:www-data, com 755/644. O PHP lê tudo, mas só escreve onde o autorizar: wp-content/uploads e eventuais diretórios de cache. As atualizações fazem-se com WP-CLI ou SFTP como utilizador de deploy, não pelo painel. Isto limita os estragos, mas dá mais trabalho. Se quiser também bloquear o painel de vez, veja DISALLOW_FILE_MODS e as suas contrapartidas.

O modelo B explica um enigma comum: o WordPress pedir credenciais de FTP quando clica em «Atualizar». O WordPress verifica se os ficheiros que criaria teriam o mesmo proprietário que os seus. Se não tiverem, recorre ao FTP. Forçar FS_METHOD para direct esconde o sintoma sem resolver a causa. Decida qual dos modelos quer e ajuste a propriedade em conformidade.

Como repor as permissões do WordPress em segurança

Faça primeiro uma cópia de segurança dos ficheiros e da base de dados. Depois, vá à raiz do WordPress e confirme que está no sítio certo:

cd /var/www/example.com/public
ls wp-config.php

Se o ls não encontrar o wp-config.php, pare. (Algumas instalações guardam-no um nível acima da raiz web, por isso confirme a sua estrutura.) Depois, reponha os modos:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Em sites grandes, a variante com + é bastante mais rápida, porque passa muitos ficheiros a cada chamada do chmod:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

Só altere a propriedade num servidor que controle. No modelo B, fica assim:

sudo chown -R deploy:www-data /var/www/example.com/public

A reposição também anula as exceções abaixo, por isso volte a aplicá-las de imediato. Depois, verifique o resultado com stat -c '%a %U:%G %n' wp-config.php wp-content/uploads, carregue uma imagem de teste e abra algumas páginas.

Exceções: wp-config.php, uploads e .htaccess

O wp-config.php contém a palavra-passe da base de dados, pelo que «outros» não devem ter qualquer acesso. Use 600 se o utilizador do PHP for o proprietário do ficheiro (modelo A). Use 640 se for um utilizador de deploy o proprietário e o PHP o ler através do grupo (modelo B). Se definir 600 no modelo B, o PHP não consegue ler o ficheiro e o site fica em baixo. Quanto a chaves (salts), definições de depuração e cópias de segurança esquecidas, veja o reforço do wp-config.php.

O wp-content/uploads e os diretórios de cache têm de ser graváveis pelo utilizador do PHP. No modelo B, ou faz do utilizador do PHP o proprietário desses diretórios, ou mantém-nos com o grupo do PHP como grupo proprietário e com escrita para o grupo (775 nos diretórios, 664 nos ficheiros). Limite a escrita a estes caminhos e não a todo o wp-content.

No Apache, o .htaccess é um caso especial. Se for gravável, o WordPress atualiza as regras de reescrita quando guarda as ligações permanentes, e os plugins de cache ou de segurança acrescentam os seus próprios blocos. Se não for, o WordPress mostra as regras para as colar manualmente. Um .htaccess só de leitura custa um pouco de comodidade. Em troca, o código executado como PHP não lhe consegue acrescentar um redirecionamento nem uma linha auto_prepend_file.

Porque o 777 nunca resolve um erro de carregamento

O 777 permite que todas as contas e todos os processos do servidor escrevam no ficheiro ou diretório. Em alojamento partilhado, isso pode incluir scripts comprometidos de outros clientes. Pode fazer o erro de carregamento desaparecer, mas só porque retira a proteção, não porque resolve a causa. Verifique as causas reais por esta ordem:

1. Proprietário errado. A mensagem «Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?» quase sempre significa que o utilizador do PHP não é o proprietário de uploads (ou não consegue escrever lá). É frequente depois de uma migração ou de um restauro feito como root.
2. Disco ou quota cheios. Execute df -h no seu próprio servidor ou consulte a quota no painel do alojamento.
3. Diretório temporário ou limites de caminho. «Missing a temporary folder» aponta para upload_tmp_dir. Uma restrição open_basedir que exclua o caminho temporário também pode bloquear carregamentos.
4. Limites de tamanho. «The uploaded file exceeds the upload_max_filesize directive» significa que tem de aumentar upload_max_filesize e post_max_size, ou carregar um ficheiro mais pequeno.

Em alojamento partilhado, normalmente não pode executar chown. Peça ao fornecedor que defina a propriedade da sua conta para o utilizador correto. É um pedido de rotina.

Contra o que as permissões corretas não protegem

As permissões limitam o que um utilizador pode fazer. Não servem de nada contra código que já corre como esse utilizador. Se um plugin vulnerável permitir a um atacante executar PHP, o código dele tem os direitos do utilizador do PHP. No modelo A, isso significa tudo. No modelo B, continua a significar os carregamentos, os diretórios de cache e tudo o mais que tenha tornado gravável. É por isso que os atacantes preferem uploads, como se explica em web shells em wp-content/uploads.

Repor as permissões depois de uma intrusão também não remove uma porta dos fundos. O ficheiro malicioso continua lá, só que com modos arrumados. Siga primeiro um plano de remoção de malware e só depois corrija as permissões, como parte do reforço da segurança. Ao abrigo do RGPD, as permissões corretas podem contar como uma das medidas técnicas que protegem a integridade e a confidencialidade dos dados pessoais (artigo 32.º, EUR-Lex), mas só funcionam como parte de um conjunto mais vasto de medidas.

Verifique as permissões com regularidade

As permissões tendem a desviar-se. Migrações, restauros de cópias de segurança, mudanças de alojamento e uma correção rápida com sudo são as causas habituais. Execute estas duas verificações a partir da raiz do WordPress depois de cada um desses eventos e, de qualquer modo, de poucos em poucos meses:

find . -perm -o+w ! -type l
find . ! -user deploy

O primeiro comando lista tudo o que tem permissão de escrita para todos (as ligações simbólicas ficam de fora porque aparecem sempre como 777). O segundo lista os ficheiros que não pertencem ao proprietário esperado. No modelo A, substitua deploy pelo utilizador do PHP. Ambos devem devolver nada, ou apenas caminhos que saiba explicar. O guia de permissões de ficheiros do WordPress.org cobre a mesma base, do ponto de vista da equipa do núcleo.

Para acompanhar o panorama completo, o plugin Security Audit & Compliance da secaudit.eu executa verificações de reforço e de configuração, além da monitorização da integridade dos ficheiros, pelo que ficheiros alterados ou novos aparecem entre as suas revisões manuais → secaudit.eu

FAQ

O wp-config.php deve ser 400 ou 440?

Também funciona, desde que o PHP continue a conseguir ler o ficheiro: 400 quando o PHP é o proprietário, 440 quando o PHP o lê através do grupo. O senão é que terá de voltar a alterar o modo para editar o ficheiro. 600 ou 640 é o compromisso habitual.

O 755/644 é seguro em alojamento partilhado?

Sim, se o fornecedor isolar as contas de modo a que o seu PHP corra com o seu próprio utilizador. Com 644, outras contas poderiam, em teoria, ler os seus ficheiros. Um isolamento correto evita isso, e é por isso que a configuração do fornecedor pesa mais do que os algarismos.

Preciso de repor as permissões a cada atualização?

Não. O WordPress cria os novos ficheiros com modos adequados. Faça antes as verificações acima e só reponha se mostrarem problemas.