drwxr-xr-x: permissões Linux explicadas

O que significa drwxr-xr-x

drwxr-xr-x descreve um diretório que o proprietário pode alterar e que todos os outros utilizadores podem ler e atravessar sem o alterar. Em octal, esse modo é 755. O Linux apresenta estes dez caracteres no início de cada linha da saída de ls -l, e eles significam sempre o mesmo, na mesma ordem. Por isso, aprender uma cadeia permite interpretar todas.

Há uma regra que vem antes das restantes, porque determina se os seus próprios testes produzem alguma informação. O utilizador root ignora os bits de permissões. O kernel concede a root a capacidade CAP_DAC_OVERRIDE (substituição do controlo de acesso discricionário), permitindo-lhe abrir ficheiros cujo modo o impediria. Todos os exemplos desta página têm êxito para root, independentemente dos bits. Inicie sessão como um utilizador normal quando quiser observar as regras em funcionamento.

Os dez caracteres, um de cada vez

Crie um diretório e um ficheiro para analisar. Nada aqui altera qualquer coisa fora do novo diretório.

mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txt

Com o umask predefinido comum de 022, as duas linhas dos diretórios começam por drwxr-xr-x e a linha do ficheiro começa por -rw-r--r--.

O caractere 1 indica o tipo de ficheiro, não uma permissão. d é um diretório. - é um ficheiro regular. l é uma ligação simbólica. c e b são nós de dispositivo de caracteres e de blocos. s é um socket e p é um named pipe. Este caractere fica fora do valor octal. Por isso, drwxr-xr-x torna-se 755, em vez de começar por d.

Os nove caracteres seguintes formam três grupos de três e nunca mudam de ordem.

• Os caracteres 2 a 4 formam a tríade do proprietário, os bits aplicáveis ao utilizador proprietário do ficheiro.
• Os caracteres 5 a 7 formam a tríade do grupo, os bits aplicáveis ao grupo do ficheiro.
• Os caracteres 8 a 10 formam a tríade dos outros, os bits aplicáveis a todos os restantes utilizadores.

Dentro de uma tríade, as posições são sempre r, depois w e depois x. Um traço significa que esse bit está desativado. As letras nunca mudam de posição. r-x significa leitura sem escrita. -w- significa escrita sem leitura, o que é permitido, mas raro.

Assim, drwxr-xr-x divide-se da seguinte forma: d para o diretório, depois rwx para o proprietário, depois r-x para o grupo e depois r-x para os outros.

Alguns sistemas apresentam um décimo primeiro caractere. Um ponto final, drwxr-xr-x., significa que o ficheiro tem um contexto SELinux (security enhanced Linux), que distribuições com SELinux, como Fedora e Rocky, apresentam por predefinição. Um sinal de mais no final, drwxr-xr-x+, significa que o ficheiro tem uma ACL POSIX (access control list), um conjunto adicional de regras além destes nove bits. Consulte essas regras adicionais com getfacl <path>.

r, w e x desempenham funções diferentes num diretório

Esta é a primeira regra que os iniciantes costumam interpretar mal. As letras são iguais num ficheiro e num diretório. As permissões que concedem não são.

• r num ficheiro lê o conteúdo. r num diretório lista os nomes existentes nele, que é o que um ls simples precisa.
• w num ficheiro altera o conteúdo. w num diretório adiciona e remove entradas nele. Apagar um ficheiro altera o diretório. Por isso, é a permissão de escrita no diretório que decide essa operação. O modo do próprio ficheiro não interfere.
• x num ficheiro executa-o como programa. x num diretório permite atravessá-lo. Isso significa que o kernel pode resolver um nome dentro dele durante a procura de um caminho.

O atravessamento é a parte que mais surpreende. x num diretório não executa nada. Abrir /srv/site/index.html precisa de x em /, depois de x em /srv, depois de x em /srv/site e, por fim, de r no ficheiro. Se um diretório dessa cadeia não tiver x para si, a procura para nesse ponto. O chamador recebe Permission denied para todo o caminho, mesmo quando o ficheiro no fim tem leitura para todos. namei -l /srv/site/index.html mostra cada passo da cadeia com o respetivo modo e proprietário, para indicar qual ligação interrompe a procura.

Um diretório com r e sem x é um estado intermédio invulgar que é importante reconhecer. Um utilizador normal pode listar os nomes, porque é isso que r concede, mas não pode obter os metadados de nenhuma entrada. Por isso, ls -l preenche as colunas de tamanho e modo com pontos de interrogação e mostra ls: cannot access ...: Permission denied para cada entrada.

Transformar as letras em 755

Cada tríade é um número de três bits. r vale 4, w vale 2 e x vale 1. Some os bits que estão ativos.

• rwx vale 4 + 2 + 1 = 7
• rw- vale 4 + 2 = 6
• r-x vale 4 + 1 = 5
• r-- vale 4
• --- vale 0

drwxr-xr-x é, portanto, 7 para o proprietário, 5 para o grupo e 5 para outros: 755. -rw-r--r-- é 6, 4, 4: 644. drwxrwxr-x é 7, 7, 5: 775, que corresponde a 755 com a permissão de escrita adicionada ao grupo. Nunca é necessário contar os caracteres manualmente, porque stat mostra as duas formas ao mesmo tempo.

stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt

%A é a forma com letras, %a é a forma octal, e %U e %G indicam o utilizador proprietário e o grupo proprietário.

As cadeias de permissões que as pessoas procuram

Estes são os modos encontrados num servidor real, com o valor octal e os locais onde cada um aparece.

• -rw-r--r-- é 644. Ficheiros comuns que um serviço apenas lê, como um ficheiro de configuração ou uma página HTML.
• -rw------- é 600. Segredos: uma chave privada SSH ou o ficheiro .env de uma aplicação.
• -rw-rw-r-- é 664. Um ficheiro num diretório partilhado por um grupo, onde os membros da equipa precisam de permissões de escrita.
• -rwxr-xr-x é 755. Scripts e binários, como /usr/local/bin/backup.sh e a maioria de /usr/bin.
• -rwx------ é 700. Um script privado que apenas o proprietário pode executar.
• drwxr-xr-x é 755. Quase todos os diretórios do sistema e o document root de um website.
• drwx------ é 700. ~/.ssh e os diretórios home num sistema com permissões restritas.
• drwxrwxr-x é 775. Um diretório no qual o grupo do proprietário pode escrever.
• drwxrwsr-x é 2775. O mesmo, com o bit setgid, para que os novos ficheiros dentro do diretório herdem o grupo do diretório.
• drwxrwxrwt é 1777. /tmp. O t final é o sticky bit, por isso um utilizador só pode apagar os próprios ficheiros.
• -rwsr-xr-x é 4755. Um binário setuid que é executado com as permissões do proprietário, como /usr/bin/passwd e /usr/bin/sudo.
• -rw-rw-rw- é 666 e drwxrwxrwx é 777. Permissões de escrita para todos, o que num servidor é quase sempre um erro.
• lrwxrwxrwx é o que todas as ligações simbólicas mostram. O Linux ignora os bits de modo de uma ligação e verifica o destino, por isso esta cadeia não tem qualquer significado.

Qual triade se aplica a si

Esta é a segunda regra que os iniciantes costumam interpretar mal. O kernel escolhe exatamente uma triade e para aí.

Se o seu ID de utilizador corresponder ao proprietário do ficheiro, recebe a triade do proprietário, e os bits do grupo e de outros utilizadores nunca são consultados. Caso contrário, se o grupo do ficheiro for um dos seus grupos, recebe a triade do grupo. Caso contrário, recebe a triade de outros utilizadores.

Isto tem duas consequências. A triade do proprietário aplica-se mesmo quando é a mais restritiva. Um ficheiro com o modo 0466, apresentado como -r--rw-rw-, dá ao proprietário apenas permissão de leitura, enquanto todos os outros podem escrever, porque a verificação do proprietário correspondeu primeiro e nada depois disso foi consultado. Isto é válido e confunde toda a gente na primeira vez que se depara com este caso.

A triade do grupo é escolhida pelo grupo do ficheiro, não pela lista de grupos a que pertence. ls -l apresenta dois nomes em cada linha: primeiro o proprietário e depois o grupo. Apenas esse segundo grupo tem influência sobre o ficheiro. Pertencer a vinte grupos só ajuda quando o ficheiro pertence a um deles.

id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txt

id apresenta o seu utilizador e todos os grupos a que pertence. stat apresenta o proprietário e o grupo do ficheiro. Compare os dois resultados para saber qual triade o kernel usará no seu caso.

É por isso que um diretório partilhado costuma receber um grupo e o bit setgid. sudo chmod 2775 /srv/shared é apresentado como drwxrwsr-x, e os ficheiros criados no seu interior passam a herdar o grupo do diretório em vez do grupo pessoal do criador. Os novos subdiretórios também recebem o bit setgid. O setgid define o grupo, não o modo. Com a umask predefinida de 022, um ficheiro novo criado no interior continua a ter o modo 644. Assim, os membros da equipa podem lê-lo, mas não podem escrever nele. Para permitir a escrita pelo grupo, todos os utilizadores que trabalham nesse diretório precisam de uma umask de 002, ou o diretório precisa de uma ACL predefinida, que substitui a umask para os ficheiros criados no seu interior. Atribuir a cada serviço a sua própria conta é a outra parte desta questão e é explicado em um utilizador Linux por serviço numa VPS.

umask define o modo de todos os ficheiros novos

Um ficheiro novo não recebe o modo diretamente de si. Recebe-o do programa que o criou, depois de remover os bits que o umask limpa. O umask é uma máscara de bits a remover. Por isso, um umask maior produz ficheiros mais privados.

A maioria das distribuições vem com 022. Um programa que cria um ficheiro normal normalmente solicita 0666. Um programa que cria um diretório normalmente solicita 0777. O umask limpa 022 de ambos os pedidos. O resultado é 644 nos ficheiros e 755 nos diretórios. Este é exatamente o par de permissões que encontra num VPS novo.

umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdir

umask -S imprime o mesmo valor como letras, o que é mais fácil de ler do que 0022. Defina umask 027 em ~/.profile para obter um valor predefinido mais restritivo: 640 nos ficheiros e 750 nos diretórios. Assim, o seu grupo pode ler o seu trabalho e mais ninguém pode. Estes resultados assumem os pedidos habituais de 0666 e 0777.

Há dois limites importantes. O umask só pode limpar bits; nunca pode adicioná-los. Um ficheiro solicitado como 0666, que é o valor pedido por touch, nunca fica executável, independentemente do valor definido. Além disso, um programa que solicita acesso apenas para o proprietário mantém essa restrição: mktemp cria ficheiros com 600 e diretórios com 700, tanto com um umask de 022 como de 027. Um serviço systemd também nunca lê o perfil da sua shell. Por isso, defina o valor no ficheiro da unidade.

[Service]
UMask=0027

Há um caso que ignora completamente o umask. Quando o diretório pai tem uma ACL predefinida, o umask é ignorado e os bits de permissão do ficheiro novo vêm da ACL herdada.

Por que os ficheiros web têm permissões 644 e os diretórios web têm permissões 755

Um servidor web é executado com a sua própria conta: www-data no Debian e Ubuntu, nginx no Rocky e Alma. Esse processo precisa de permissão de leitura nos ficheiros que serve e de permissão para atravessar os diretórios acima deles. Não tem motivo para escrever nesses ficheiros, e um site estático nunca deve permitir isso.

A permissão 644 num ficheiro dá escrita ao proprietário e leitura a todos. Assim, o utilizador de deployment pode publicar e o utilizador do servidor web pode servir os ficheiros. A permissão 755 num diretório dá escrita ao proprietário e permissão para atravessar o diretório a todos. Assim, o utilizador do servidor web pode percorrer o caminho sem conseguir adicionar ou eliminar nada. Um erro na aplicação não consegue então reescrever as páginas que está a servir.

A regra de atravessamento é aplicada exatamente neste ponto. Se o site estiver em /home/deploy/site, /home/deploy for 750 e o utilizador do servidor web não pertencer ao grupo do diretório, esse utilizador não consegue sequer entrar no diretório home. O pedido termina com HTTP 403 e uma linha semelhante a esta em /var/log/nginx/error.log:

open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5

Esse 13 é EACCES, a recusa de permissões do kernel. Não há nenhum problema na rede: a porta está a escutar e o pedido chegou. É isso que torna este caso confuso enquanto ainda está a aprender como funcionam as portas em escuta no Linux. Execute namei -l /home/deploy/site/index.html e percorra a cadeia até encontrar o primeiro diretório sem x para outros.

Um diretório onde a aplicação escreve, como um caminho de uploads, é uma exceção. Conceda essa permissão através da propriedade, e não com um modo mais permissivo: sudo chown -R www-data:www-data /srv/site/uploads, mantendo o modo em 755. Mantenha o acesso de escrita apenas no diretório que precisa dele.

chmod sem alterar toda a árvore

chmod aceita as duas formas. O modo octal define os nove bits de uma só vez: chmod 644 notes.txt. O modo simbólico altera apenas o que é especificado e mantém o restante inalterado: chmod u+x deploy.sh adiciona a permissão de execução ao proprietário, e chmod go-w notes.txt remove a permissão de escrita do grupo e de outros utilizadores.

A recursão é o ponto em que as árvores de diretórios ficam danificadas. chmod -R 755 . torna executáveis todas as imagens e todos os ficheiros de configuração, porque chmod não consegue distinguir um script de um JPEG. Em vez disso, use o X em maiúsculas.

chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txt

X em maiúsculas aplica a permissão de execução aos diretórios e aos ficheiros que já tinham algum bit de execução definido. Os diretórios ficam com 755, os ficheiros comuns ficam com 644 e os scripts que já eram executáveis mantêm essa permissão. Quando um ficheiro já tem um modo de permissões de confiança, chmod --reference=good.sh other.sh copia esse modo para os restantes.

As mensagens apresentadas quando algo está errado

bash: ./deploy.sh: Permission denied significa que o script não tem o bit x no trio aplicável ao seu caso, ou que algum diretório no respetivo caminho não tem x. chmod u+x deploy.sh corrige o primeiro caso.

bash: ./deploy.sh: cannot execute: required file not found é uma falha diferente, com um nome confuso. O bit x está correto, mas falta o interpretador indicado na primeira linha. A causa habitual são terminações de linha do Windows, fazendo com que o kernel procure um interpretador chamado /bin/bash\r. Corrija com sed -i 's/\r$//' deploy.sh.

Permissions 0644 for '/home/deploy/.ssh/id_ed25519' are too open. vem do cliente SSH, que se recusa a utilizar uma chave privada que possa ser lida por outras contas. A chave deve ter 600 e ~/.ssh deve ter 700. O tratamento completo de chaves está em gerir chaves SSH e as respetivas permissões de ficheiros.

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh aparece no journal do servidor quando um diretório pessoal ou o respetivo .ssh permite escrita pelo grupo. A definição StrictModes do sshd rejeita a chave. No lado do cliente, isso surge como um pedido inesperado de palavra-passe, sem explicação.

sudo: /etc/sudoers is world writable, seguido de sudo: no valid sudoers sources found, quitting, significa que o sudo verificou o modo da sua própria configuração e recusou-se a executar. Esse ficheiro deve ter 0440 e nunca pode permitir escrita global. Esta é a consequência clássica de um chmod recursivo aplicado de forma abrangente. Também pode surgir juntamente com a mensagem do sshd acima, deixando a consola do fornecedor como a única forma de recuperar o acesso.

Por que 777 não é uma correção

777 dá acesso de escrita a todas as contas da máquina e a todos os processos executados por essas contas. Um servidor executa serviços com utilizadores próprios, por isso "todos" abrange muito mais num VPS do que num portátil. Um serviço comprometido pode escrever em qualquer local permitido por 777.

Num diretório raiz de um site, o impacto é direto. Um diretório com permissão de escrita para todos, que também seja servido pelo servidor, transforma uma falha no upload de ficheiros numa forma de colocar um script no servidor e depois solicitar esse script.

777 quase nunca é a resposta correta para um problema de propriedade. O sintoma é "a aplicação não consegue escrever neste diretório". A causa é o diretório pertencer ao utilizador errado. sudo chown -R appuser:appuser /srv/app/storage com o modo 755 resolve o problema: a aplicação pode escrever nesse diretório, e todas as outras contas continuam a poder listar e entrar no diretório, mas não podem escrever nele. Criar essas contas antes de qualquer implementação faz parte de os primeiros dez minutos num VPS novo.

A escrita para todos é legítima num local conhecido, /tmp, e escreve-se drwxrwxrwt. O t final é o sticky bit: o diretório pode ser escrito por todos, mas cada utilizador só pode apagar os ficheiros que lhe pertencem. Sem esse bit, qualquer conta poderia apagar os ficheiros temporários de outra conta.

Leia o modo antes de o alterar

Estes comandos apenas consultam o estado, por isso são seguros para executar em qualquer local.

id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002

find <path> -perm -0002 lista tudo sob um caminho cujo bit de escrita para outros utilizadores está definido. É a forma mais rápida de auditar um servidor depois de alguém ter corrigido ficheiros com chmod 777.

Para verificar se uma determinada conta de serviço pode entrar num diretório, faça a consulta com essa conta. sudo -u www-data test -x /srv/site && echo yes || echo no imprime yes quando esse utilizador tem permissão de travessia no diretório e no quando não tem. Fazer a consulta como root não prova nada, porque root ignora essa verificação e a resposta é sempre yes.

FAQ

O que significa drwxr-xr-x no Linux?

É um diretório, indicado pelo d inicial, com o modo 755. A tríade do proprietário é rwx, por isso o proprietário tem todas as permissões. A tríade do grupo é r-x e a tríade dos outros é r-x, por isso todas as outras contas podem listar os nomes existentes e atravessar o diretório, mas apenas o proprietário pode adicionar ou remover itens. Confirme qualquer caminho com stat -c '%A %a %U %G %n' <path>, que apresenta a forma literal e a forma octal lado a lado.

Por que os ficheiros web têm 644 e os diretórios web têm 755?

O servidor web é executado com uma conta diferente, www-data no Ubuntu. Precisa de ler os ficheiros que serve e de atravessar todos os diretórios acima deles, mas não precisa de escrever em nenhum dos dois. 644 dá permissão de escrita ao proprietário e de leitura a todas as outras contas. 755 dá permissão de escrita ao proprietário e de travessia a todas as outras contas. Um diretório no qual a aplicação realmente precisa de escrever deve ser atribuído com chown ao utilizador dessa aplicação, em vez de alargar o modo para todas as contas.

O bit x significa que posso executar um diretório?

Não. Num diretório, x significa travessia, ou seja, o direito de resolver um nome dentro dele enquanto o kernel percorre um caminho. cd precisa dessa permissão, tal como qualquer abertura de um ficheiro abaixo desse diretório. Cada diretório no caminho precisa de x, por isso um ficheiro com o modo 644 continua inacessível quando um diretório acima dele não tem x para si. namei -l /path/to/file apresenta o modo de todos os diretórios na cadeia, mostrando onde a resolução do caminho para.

chmod 777 é alguma vez a solução correta?

Quase nunca num servidor. Concede permissão de escrita a todas as contas da máquina, incluindo as contas usadas pelos serviços, por isso um serviço comprometido pode reescrever o ficheiro. Quando uma aplicação não consegue escrever num diretório, o problema real costuma ser o proprietário: sudo chown -R appuser:appuser /srv/app/storage com o modo 755 dá acesso de escrita à aplicação, enquanto as outras contas continuam a poder ler o diretório, mas não podem escrever nele. A exceção conhecida é /tmp com 1777, e isso só funciona porque o sticky bit impede os utilizadores de eliminarem os ficheiros uns dos outros.

Por que o ls apresenta um ponto ou um sinal de mais depois das permissões?

Esse décimo primeiro carácter descreve regras adicionais aos nove bits de permissão. Um ponto, como em drwxr-xr-x., significa que está associado um contexto de segurança SELinux, o que é normal no Fedora e no Rocky. Um sinal de mais, como em drwxr-xr-x+, significa que está definida uma ACL POSIX (lista de controlo de acesso), por isso algum utilizador ou grupo tem direitos que as três tríades não apresentam. Execute getfacl <path> para listar essas entradas adicionais.