Ler e definir corretamente as permissões de ficheiros no seu VPS
Cada ficheiro e cada pasta no seu VPS tem um proprietário, um grupo e permissões. Se forem demasiado permissivas, um site ou serviço comprometido pode escrever em qualquer lado. Se forem demasiado restritivas, surgem erros como "Permission denied" ou um 403 no seu site. Neste artigo explicamos como ler e definir corretamente as permissões. Se tiver um alojamento com DirectAdmin, consulte Proibido (403): não tem permissão para aceder a / neste servidor.
Ler permissões com ls -l
ls -l /var/www/example.com -rw-r--r-- 1 anna www-data 1520 index.html -rw-r----- 1 anna www-data 412 config.php drwxr-xr-x 2 anna www-data 4096 images drwxrwxr-x 2 www-data www-data 4096 uploads
O primeiro carácter indica o tipo: - é um ficheiro, d uma pasta, l uma ligação simbólica. Seguem-se três grupos de três caracteres: o que o proprietário pode fazer, o que o grupo pode fazer e o que todos os outros podem fazer. Depois aparecem o proprietário (anna) e o grupo (www-data).
| Letra | Num ficheiro | Numa pasta |
|---|---|---|
r | Ler | Listar os nomes contidos na pasta |
w | Modificar | Criar, mudar o nome e eliminar ficheiros |
x | Executar como programa | Entrar na pasta e abrir os ficheiros nela contidos |
Tenha em atenção dois pontos. Sem x numa pasta, não consegue aceder aos ficheiros que nela se encontram, mesmo que estes sejam legíveis. E quem tiver w numa pasta pode eliminar ficheiros dentro dela, mesmo que pertençam a outra pessoa.
Permissões em formato numérico
É frequente escrever as permissões com três algarismos: r vale 4, w 2 e x 1, somados por grupo.
| Número | Permissões | Utilização |
|---|---|---|
| 644 | rw-r--r-- | Ficheiro comum, por exemplo uma página web ou uma imagem |
| 755 | rwxr-xr-x | Pasta, ou um programa que todos podem utilizar |
| 640 | rw-r----- | Configuração com uma palavra-passe, legível pelo servidor web através do grupo |
| 600 | rw------- | Ficheiro secreto, como authorized_keys, uma chave privada ou um ficheiro .env |
| 700 | rwx------ | Pasta privada, como ~/.ssh |
Alterar permissões e proprietário
chmod 640 /var/www/example.com/config.php chmod g+w /var/www/example.com/uploads sudo chown anna:www-data /var/www/example.com/config.php
chmod altera as permissões, com um número ou com letras (u, g, o para proprietário, grupo e outros, com + ou -). chown proprietário:grupo altera o proprietário e o grupo; apenas o root o pode fazer, por isso utilize sudo.
Para uma pasta inteira, chmod -R 644 é um erro comum: todas as subpastas perdem o x e ficam inutilizáveis. Defina as pastas e os ficheiros separadamente com find:
sudo find /var/www/example.com -type d -exec chmod 755 {} +
sudo find /var/www/example.com -type f -exec chmod 644 {} +
O servidor web através do grupo
Em Debian e Ubuntu, o nginx e o PHP-FPM são executados por predefinição com o utilizador www-data. Uma organização correta: o utilizador é o proprietário dos ficheiros e o grupo é www-data. Assim, o servidor web pode ler através do grupo e escrever apenas na pasta onde isso é realmente necessário, como uploads (chmod g+w ou proprietário www-data apenas nessa pasta). Não dê ao servidor web permissão de escrita nos seus ficheiros PHP.
777. Nesse caso, qualquer pessoa no servidor pode ler, modificar e executar o ficheiro ou a pasta. Se algum dia um site ou serviço for comprometido, o intruso pode escrever em todos os locais com 777. O verdadeiro problema é quase sempre o proprietário ou o grupo: resolva isso em vez de abrir tudo.Permissões para SSH
O servidor SSH verifica as permissões das suas chaves. Se outros utilizadores puderem escrever na sua pasta .ssh ou na sua pasta pessoal, a chave é ignorada e volta a ser pedida a palavra-passe, sem uma mensagem de erro clara. Defina-as da seguinte forma:
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
Se criou a pasta como root para outro utilizador, corrija também o proprietário, tal como em Um utilizador próprio com sudo. Em AlmaLinux e Rocky Linux, o SELinux também pode recusar um ficheiro que tenha as permissões corretas; no caso de uma pasta .ssh criada manualmente, restorecon -Rv ~/.ssh resolve a situação.
s em vez de um x, como em /usr/bin/passwd? Trata-se do bit setuid: o programa é executado com as permissões do proprietário. Alguns programas do sistema precisam dele, mas nunca o defina num script. Um ficheiro setuid inesperado pode indicar uma intrusão; consulte Pirateado? Os primeiros passos.Quer saber mais? Frequente o curso gratuito de VPS e administração de servidores Linux, lição 3.1 Utilizadores, grupos e permissões de ficheiros.