Como funcionam as permissões de ficheiro em Unix: ler 755 sem adivinhar

Três dígitos, três partes, e só uma se aplica

Na saída de `ls -l` o primeiro carácter indica o tipo — um travessão para um ficheiro normal, d para um diretório, l para uma ligação simbólica — e os nove seguintes são três grupos de três: dono, grupo, outros. O que surpreende é que não se acumulam. O núcleo escolhe a primeira classe a que pertence e para aí. Se for o dono de um ficheiro em 477 obtém r-- e mais nada, mesmo com os bits de grupo e outros escancarados: a classe do dono correspondeu primeiro e o resto nunca é consultado.

Há duas formas de escrever uma alteração e não são equivalentes. O octal é absoluto: `chmod 644 notes.txt` fixa o modo inteiro e apaga o que lá estivesse antes. O simbólico é relativo: `chmod u+x script.sh` acrescenta um bit e deixa os outros oito intactos. Num script de implantação quer quase sempre a forma octal, porque produz o mesmo estado final seja qual for o aspeto do ficheiro à chegada.

Num diretório, o bit de execução é um direito completamente diferente

Nada é jamais executado por se dar o bit x a um diretório. Num diretório esse bit é permissão de pesquisa: deixa um processo resolver um nome lá dentro e alcançar o que está por trás. A separação vê-se com facilidade. Ponha um diretório em 400 e o `ls` imprimirá de bom grado os nomes que contém, mas cada consulta falha e `cat dir/ficheiro` é recusado — vê as etiquetas e não toca em nada. Ponha-o em 100 e acontece o inverso: não consegue listar nada, mas se já souber o caminho exato abre o ficheiro. Essa assimetria explica que um diretório pessoal em 711 funcione: os outros alcançam ~/public_html sem poderem enumerar o resto.

A mesma lógica explica um resultado que parece um erro. Apagar um ficheiro não é uma modificação do ficheiro: é uma modificação do diretório que o lista. Portanto a permissão que decide se um ficheiro pode ser removido é escrita mais execução sobre o diretório que o contém, e o modo do próprio ficheiro é irrelevante. Um ficheiro em 444 dentro de um diretório em 777 pode ser apagado por qualquer pessoa na máquina. É exatamente o buraco que o sticky bit foi inventado para tapar, e por isso /tmp é 1777 e não 0777.

O quarto dígito e porque o umask não é uma permissão

Três bits especiais vivem num dígito inicial opcional. Setuid é 4000: num binário executável fá-lo correr com a identidade do dono, que é como o passwd edita um ficheiro que o utilizador não pode. No Linux é ignorado em silêncio em scripts interpretados e não significa nada num diretório. Setgid é 2000: num binário faz o mesmo para o grupo, e num diretório faz algo bem mais útil — as entradas novas herdam o grupo do diretório em vez do de quem as cria, e os subdiretórios novos herdam também o bit setgid, a forma padrão de manter coerente uma árvore de projeto partilhada. O sticky é 1000: num diretório restringe apagar e renomear uma entrada ao dono da entrada, ao dono do diretório ou ao root.

O umask é a peça que mais se inverte. Não é a permissão que os ficheiros novos recebem: é uma máscara de bits a retirar do que o programa criador pediu. Os programas pedem 666 para um ficheiro e 777 para um diretório, e cada bit posto no umask é desligado. Com o umask comum 022 obtém portanto 644 para ficheiros e 755 para diretórios. E limpa em vez de subtrair: umask 023 continua a dar 644 num ficheiro novo, não 643, porque o ficheiro nunca pediu o bit de execução e não há nada a tirar. Outro parente próximo: `chmod +x` sem letra de classe não equivale a `chmod a+x`, porque a forma nua respeita também o seu umask — sob umask 077 concede a execução apenas ao dono.

Perguntas frequentes

Porque é que chmod 777 é a solução errada?

Dá acesso de escrita a todas as contas da máquina, incluindo a identidade sob a qual corre o seu servidor web ou um processo comprometido, e código escrevível por todos é código que qualquer pessoa pode substituir. Costuma também falhar a causa real, que é mais vezes uma propriedade errada ou um bit de execução em falta num diretório pai do que uma permissão demasiado estreita. Alguns programas recusam-se de vez: o OpenSSH ignora uma chave privada ou um authorized_keys escrevível pelo grupo ou por todos.

chmod 755 torna um script executável?

Concede permissão para tentar, o que não é o mesmo que fazê-lo funcionar. Um ficheiro de texto precisa também de uma linha shebang que nomeie um interpretador existente, ou o núcleo não tem a quem entregá-lo. Duas outras coisas sobrepõem-se por completo ao modo: um sistema de ficheiros montado com a opção noexec recusa executar seja o que for, digam os bits o que disserem, e cada diretório do caminho até ao ficheiro precisa do seu próprio bit de execução para que o ficheiro seja sequer alcançável.

Porque é que alguém pode apagar um ficheiro que pus só de leitura?

Porque apagar é uma alteração ao diretório, não ao ficheiro. O núcleo verifica escrita e execução no diretório que guarda o nome e nunca olha para o modo do ficheiro. Para o impedir, aperte o diretório ou ponha-lhe o sticky bit, que limita apagar e renomear ao dono da entrada, ao dono do diretório e ao root — a razão de um /tmp partilhado ser 1777.