Permissões no Linux: o que os números do chmod querem mesmo dizer

Há um reflexo que quase toda a gente já teve pelo menos uma vez: alguma coisa não funciona por causa de permissões, escreve-se chmod 777, e passa a funcionar. Resolveu — e é precisamente por resolver que o hábito pega.

Vale a pena perceber o que os três números dizem, porque depois disso o 777 deixa de ser tentador. Não é o valor mais permissivo de uma escala: é a desistência de a usar.

1. Três dígitos, três públicos

Cada ficheiro tem um dono, um grupo e «os outros» — toda a gente no sistema. Cada dígito do chmod é para um deles, por essa ordem.

chmod 750 publicar.sh
#       │││
#       ││└── outros: 0 = nada
#       │└─── grupo:  5 = ler + executar
#       └──── dono:   7 = ler + escrever + executar

E cada dígito é a soma de três valores:

• 4 — ler (r)

• 2 — escrever (w)

• 1 — executar (x)

Não há combinações a decorar. O 6 é 4+2, ler e escrever. O 5 é 4+1, ler e executar. O 7 é tudo. E o 777 lê-se, sem margem nenhuma para dúvidas, como «qualquer pessoa nesta máquina pode ler, alterar e executar isto».

2. O x numa pasta não é o que parece

É aqui que a intuição falha. Numa pasta, os mesmos três bits querem dizer outra coisa:

• r — listar o que está lá dentro, ou seja, fazer ls

• w — criar e apagar entradas lá dentro

• x — atravessar a pasta, isto é, chegar ao que está lá dentro

A consequência prática é que uma pasta sem x é uma pasta onde nada funciona, mesmo que os ficheiros lá dentro tenham as permissões certas. Ninguém lá chega para as usar.

E há uma que apanha toda a gente mais cedo ou mais tarde: apagar um ficheiro não depende das permissões do ficheiro. Depende do w da pasta que o contém. O nome do ficheiro é uma entrada na pasta, e remover essa entrada é escrever na pasta — mesmo que o ficheiro em si esteja a 444 e nem sequer seja seu.

3. Ler o ls -l sem hesitar

ls -l
# drwxr-xr-x  2 fnsp  fnsp   4096 Sep  4 10:12 publico
# -rw-------  1 fnsp  fnsp    812 Sep  4 10:12 .env
# -rwxr-xr-x  1 root  root  35168 Aug 21 09:03 publicar.sh
# │└┬┘└┬┘└┬┘
# │ │  │  └── outros
# │ │  └───── grupo
# │ └──────── dono
# └────────── tipo: d = pasta, - = ficheiro, l = atalho

O drwxr-xr-x da primeira linha é o 755 escrito por extenso, e o -rw------- da segunda é o 600. É a mesma informação em duas notações.

4. Os quatro valores que resolvem quase tudo

chmod 644 nota.md             # ficheiros normais: o dono altera, os outros leem
chmod 755 publicar.sh         # o mesmo, mas executável
chmod 600 .env                # segredos: mais ninguém lê
chmod 700 ~/.ssh              # a pasta das chaves, só sua

O SSH leva isto tão a sério que se recusa a usar uma chave privada que o resto do sistema consiga ler. Aquele UNPROTECTED PRIVATE KEY FILE em maiúsculas, que aparece de vez em quando depois de copiar chaves de uma máquina para outra, é exatamente isto: a chave chegou com 644 e o cliente prefere falhar a arriscar.

5. O -R que estraga mais do que arruma

Este é o segundo reflexo mau, e é irmão do primeiro. Pastas precisam de x, ficheiros de texto não — e o -R não distingue os dois.

# Errado: deixa todos os .md, .png e .env executáveis
chmod -R 755 /var/www/site

# Certo: uma regra para pastas, outra para ficheiros
find /var/www/site -type d -exec chmod 755 {} +
find /var/www/site -type f -exec chmod 644 {} +

Há uma forma mais curta de dizer o mesmo, e vale a pena conhecê-la: o X maiúsculo só põe o bit de execução em pastas e em ficheiros que já o tenham.

chmod -R u=rwX,go=rX /var/www/site

6. Muitas vezes o problema não é o modo, é o dono

Quando o 777 «resolve», o que costuma estar errado é outra coisa: o processo corre como um utilizador e os ficheiros pertencem a outro. Abrir as permissões a toda a gente contorna o sintoma; o chown trata da causa.

chown -R fnsp:fnsp /var/www/site

E há aqui um pormenor que só se percebe depois de bater algumas vezes com a cabeça: o sistema de ficheiros não guarda nomes, guarda números. O fnsp que o ls mostra é uma tradução feita na hora a partir do /etc/passwd.

Dentro de um contentor Docker o /etc/passwd é outro. O mesmo UID 1000 pode chamar-se node lá dentro e fnsp cá fora — e é por isso que um volume montado aparece por vezes a pertencer a um utilizador que «não existe»: o número está lá, o nome é que não tem tradução daquele lado. A saída é acertar o UID, não abrir o volume a toda a gente.

id -u   # 1000 — o meu UID no anfitrião

docker run --user 1000:1000 -v "$PWD:/app" -w /app node:22 npm run build

7. Quem decide as permissões de um ficheiro novo

Ninguém escreve chmod de cada vez que cria um ficheiro, e no entanto ele nasce com permissões. Quem as decide é a umask, que funciona ao contrário do chmod: em vez de dizer o que permitir, diz o que retirar.

umask           # 0022 — retira o w ao grupo e aos outros

touch nota.md   # nasce 644
mkdir pasta     # nasce 755

É também aqui que se percebe porque é que um ficheiro criado por um serviço do sistema aparece às vezes com permissões estranhas: a umask daquele contexto não era a da sua sessão.

8. Porque é que o 777 não é só «exagerado»

• Escrever é executar, quando o servidor corre o que lá está. Num sítio de onde o servidor executa código, tudo o que for escrevível por outros é código que outros podem substituir. É assim que uma pasta de uploads a 777 se transforma numa consola remota.

• «Os outros» não é uma abstração. Numa máquina partilhada, ou numa máquina com vários serviços a correr sob utilizadores diferentes, «os outros» são processos concretos — e basta um deles ser comprometido.

• Esconde o problema a sério. O 777 faz o erro desaparecer sem dizer qual era. Meses depois, ninguém sabe se aquela pasta precisa mesmo daquilo ou se foi um empurrão de uma tarde má.

Por onde começar quando dá erro

A ordem de diagnóstico é sempre a mesma, e o modo é o último passo e não o primeiro: primeiro como quem corre o processo — id, ou o USER do contentor; depois de quem são os ficheiros, com ls -l; só então o modo. Na maior parte das vezes a resposta está nos dois primeiros pontos, e o chmod nunca chega a ser preciso.