chmod no Linux: permissões rwx e os números 755, 644 e 600

No Linux, cada arquivo e pasta tem permissões que definem quem pode ler, escrever e executar. O comando chmod (change mode) é o que ajusta essas permissões. Entender chmod evita dois extremos comuns: o erro de permissão que trava um deploy e o exagero de liberar tudo com 777, que cria risco de segurança. Neste guia você aprende a ler a saída do ls -l, a montar o octal (755, 644, 600), a usar a notação simbólica, os bits especiais setuid, setgid e sticky, a umask e os erros que mais aparecem no dia a dia. Para montar e conferir permissões na prática, use as ferramentas DevOps, que calculam o octal e o simbólico localmente.

O que é chmod

chmod altera o modo de acesso de um item do sistema de arquivos. Ele aceita as permissões de duas formas: pela notação octal (três números, como 644) ou pela notação simbólica (como u+x para adicionar execução ao dono). As duas chegam ao mesmo resultado. A octal é mais comum em scripts e documentação por ser compacta; a simbólica é melhor para mexer em um bit sem recalcular o resto. O comportamento do comando está definido no padrão POSIX e vale igual em Linux, macOS e BSD, com pequenas diferenças de opções entre as implementações.

Como ler a saída do ls -l

Antes de mudar permissão, aprenda a ler o que já existe. Rode ls -l e observe uma linha típica:

-rwxr-xr-x 1 maria devs 2048 jul 18 10:30 deploy.sh

O primeiro caractere indica o tipo do item: hífen para arquivo comum, d para diretório, l para link simbólico (há outros, como b e c para dispositivos). Os nove caracteres seguintes são as permissões em três trios: os três primeiros são do dono (rwx), os três do meio são do grupo (r-x) e os três finais são dos outros (r-x). Depois vêm o número de links, o dono (maria) e o grupo (devs). Nesse exemplo, maria pode tudo; quem está no grupo devs e todo o resto pode ler e executar, mas não alterar. Para ver a permissão de uma pasta em si, e não do conteúdo dela, use ls -ld pasta.

Dono, grupo e outros

As permissões são divididas em três classes, sempre nesta ordem:

• Owner (dono): o usuário dono do arquivo.
• Group (grupo): o grupo associado ao arquivo.
• Others (outros): todos os demais usuários do sistema.

O sistema decide qual trio aplicar na ordem: se você é o dono, valem as permissões do dono; senão, se pertence ao grupo, valem as do grupo; senão, valem as dos outros. Só uma classe é aplicada por vez. Um detalhe que surpreende: se o dono tem 0 e os outros têm 7, o próprio dono fica sem acesso, porque a classe dele é avaliada primeiro.

Permissões r, w e x

Cada classe tem três permissões. Em arquivos, r deixa ler o conteúdo, w deixa modificar e x deixa executar como programa. Em pastas, r deixa listar os nomes, w deixa criar e remover itens, e x deixa entrar na pasta e acessar o que há dentro. Essa diferença é a causa de muitos erros: uma pasta sem x fica inacessível, mesmo com r. E como apagar um arquivo é uma operação na pasta (remover o nome dela), quem tem w na pasta consegue apagar arquivos que não pode nem ler.

A notação octal completa

Some os valores das permissões de cada classe: leitura vale 4, escrita vale 2 e execução vale 1. O resultado é um dígito de 0 a 7. A tabela cobre as oito combinações possíveis:

Na prática, os dígitos 1, 2 e 3 quase não aparecem em arquivos comuns: executar sem poder ler só faz sentido em casos raros, e escrever sem ler é usado em situações bem específicas, como caixas de depósito. O repertório real do dia a dia gira em torno de 0, 4, 5, 6 e 7.

A notação simbólica: u, g, o, a e os operadores

A forma simbólica indica quem (u para dono, g para grupo, o para outros, a para todos), a operação (+ adiciona, - remove, = define exatamente) e a permissão (r, w, x). Dá para combinar várias cláusulas separadas por vírgula. Exemplos que cobrem quase tudo:

• chmod u+x deploy.sh: adiciona execução só ao dono.
• chmod +x deploy.sh: adiciona execução a todas as classes (respeitando a umask); é o atalho mais digitado do comando.
• chmod go-w config.yml: remove escrita de grupo e outros.
• chmod a=r LEIAME.txt: deixa todos apenas com leitura, apagando o que havia antes.
• chmod u=rw,g=r,o= segredo.txt: dono lê e escreve, grupo só lê, outros ficam sem nada (equivale a 640).

O = merece atenção: ele substitui o trio inteiro da classe. Um chmod u=r arquivo tira a escrita e a execução do dono, mesmo que você só quisesse garantir a leitura. Quando a intenção é adicionar sem apagar, fique no +.

O que significa chmod 755

755 é rwxr-xr-x. O dono tem controle total; grupo e outros podem ler e executar, mas não escrever. É o padrão de pastas e de executáveis, porque todos precisam acessar, mas só o dono deve modificar. Num servidor web típico, as pastas do site ficam em 755 para que o processo do servidor consiga atravessá-las.

O que significa chmod 644

644 é rw-r--r--. O dono lê e escreve; grupo e outros apenas leem. É a permissão típica de arquivos comuns, como páginas, imagens e documentos servidos por um site, onde ninguém além do dono deve alterar o conteúdo. Repare que 644 não tem x: um HTML não precisa ser executável, e um script de shell com 644 falha com erro de permissão até receber o bit x.

O que significa chmod 600 e 700

600 é rw-------: apenas o dono lê e escreve, e mais ninguém tem acesso. É a permissão exigida para arquivos privados, como chaves SSH, arquivos .env com senhas e credenciais de banco. 700 é a versão para pastas privadas (rwx------), como a ~/.ssh, em que o dono precisa do x para entrar. A dupla 600 no arquivo e 700 na pasta resolve a maioria dos casos de segredo local.

Pasta compartilhada de equipe: 664 e 775

Quando um grupo de pessoas edita os mesmos arquivos, a escrita do grupo entra em cena: 664 (rw-rw-r--) para arquivos e 775 (rwxrwxr-x) para pastas permitem que qualquer membro do grupo modifique, enquanto os demais usuários só leem. Esse par costuma vir acompanhado do bit setgid na pasta, explicado adiante, para que os arquivos novos já nasçam com o grupo certo.

Valores de permissão mais usados

Exemplos práticos

• chmod 755 deploy.sh: torna o script executável por todos, editável só pelo dono.
• chmod 644 index.html: arquivo legível por todos, gravável só pelo dono.
• chmod 600 ~/.ssh/id_ed25519: chave privada acessível só pelo dono.
• chmod 700 ~/.ssh: pasta de chaves acessível só pelo dono.
• chmod 600 .env: arquivo de variáveis com senha fora do alcance de outros usuários.
• chmod 775 /srv/projetos: pasta em que todo o grupo pode criar e editar arquivos.

chmod -R: o recursivo e o perigo do x

A opção -R aplica a permissão em toda a árvore de pastas. Ela é útil e traiçoeira ao mesmo tempo, porque pastas e arquivos precisam de coisas diferentes. Um chmod -R 644 site/ tira o x das pastas e torna tudo inacessível. Um chmod -R 755 site/ resolve o acesso, mas marca cada HTML e imagem como executável, o que suja o sistema e dispara alertas em auditorias de segurança.

A saída elegante é o X maiúsculo da notação simbólica: chmod -R u=rwX,go=rX site/. O X só concede execução a diretórios e a arquivos que já tinham x para alguma classe. Ou seja: as pastas ganham o x de que precisam e os arquivos comuns continuam sem execução. Quando preferir octal puro, separe os alvos com find:

• find /var/www/site -type d -exec chmod 755 {} +: aplica 755 só em diretórios.
• find /var/www/site -type f -exec chmod 644 {} +: aplica 644 só em arquivos.

Pense duas vezes antes de qualquer recursivo em pastas do sistema. Um chmod -R errado em /etc ou /usr pode exigir restauração do sistema, porque muitos programas conferem as próprias permissões e se recusam a rodar quando elas mudam.

setuid, setgid e sticky bit: o quarto dígito

Além dos nove bits de rwx, existem três bits especiais, escritos como um quarto dígito na frente do octal: 4 para setuid, 2 para setgid e 1 para o sticky bit. Eles mudam o comportamento do arquivo ou da pasta, não só o acesso.

setuid (4xxx) faz um executável rodar com a identidade do dono do arquivo, e não de quem o chamou. O exemplo clássico é o /usr/bin/passwd, que aparece no ls -l como -rwsr-xr-x (o s no lugar do x do dono, octal 4755): qualquer usuário troca a própria senha, mas o programa precisa de root para gravar no arquivo de senhas do sistema. Não coloque setuid em scripts: o kernel do Linux ignora o bit em scripts interpretados, justamente por risco de segurança.

setgid (2xxx) tem dois usos. Em executável, roda com o grupo do arquivo. Em pasta, o efeito é mais útil no dia a dia: os arquivos criados ali herdam o grupo da pasta, e não o grupo primário de quem criou. É a receita da pasta de equipe: chmod 2775 /srv/projetos (ou chmod g+s numa pasta que já é 775) garante que tudo que nascer dentro pertença ao grupo do time.

sticky bit (1xxx) em pasta restringe a exclusão: mesmo com escrita liberada, cada usuário só apaga os próprios arquivos (o dono da pasta e o root apagam qualquer um). O /tmp é o caso canônico: drwxrwxrwt, octal 1777. Todos gravam ali, mas ninguém apaga o arquivo temporário do vizinho. Na notação simbólica, o bit entra com chmod +t pasta.

Uma curiosidade de leitura: s e t minúsculos indicam o bit especial com o x presente por baixo; S e T maiúsculos indicam o bit especial sem o x, o que quase sempre é um erro de configuração.

umask: de onde vem a permissão inicial

Você já deve ter notado que arquivos novos nascem 644 e pastas novas nascem 755 sem que ninguém rode chmod. Quem define isso é a umask, uma máscara que remove bits das permissões pedidas na criação. Arquivos comuns são criados a partir de 666 (programas normalmente não pedem x) e pastas a partir de 777. A conta, nos valores usuais, funciona como uma subtração dígito a dígito:

• umask 022: arquivos 666-022 = 644, pastas 777-022 = 755 (padrão da maioria das distros).
• umask 002: arquivos 664, pastas 775 (comum em sistemas com grupo por usuário).
• umask 077: arquivos 600, pastas 700 (nada para grupo e outros; bom padrão em servidores multiusuário).

A rigor a umask é uma remoção de bits, não uma subtração aritmética, mas nos valores comuns as duas contas coincidem. O comando umask sem argumento mostra o valor atual; umask 027 altera a máscara da sessão, e a mudança permanente vai no perfil do shell (~/.profile ou ~/.bashrc). Conhecer a umask evita chmod corretivo em série depois de criar dezenas de arquivos.

chmod, chown e chgrp: permissão e dono são coisas diferentes

Permissão responde o que cada classe pode fazer; dono e grupo respondem quem cai em cada classe. Os comandos chown e chgrp mexem nesse segundo lado: sudo chown maria:devs relatorio.txt troca dono e grupo de uma vez, e chgrp devs relatorio.txt troca só o grupo. Trocar o dono exige root; o dono comum pode mudar o grupo do próprio arquivo para outro grupo do qual participe.

Muitos problemas atribuídos ao chmod são, na verdade, de dono. Num servidor web, se os arquivos pertencem ao usuário errado, nenhum 755 resolve direito: o caminho é sudo chown -R www-data:www-data /var/www/site e, depois, 755 nas pastas e 644 nos arquivos. Diagnostique com ls -l antes de sair abrindo permissão: a coluna do dono e do grupo diz em qual classe o processo do servidor está caindo.

Erros comuns e como resolver

chmod 777 como conserto universal. O 777 aparece em tutoriais antigos como solução rápida, e funciona no sentido de fazer o erro sumir. O custo é alto: qualquer usuário ou processo comprometido do sistema passa a poder alterar os arquivos, o que em servidores expostos vira vetor de invasão. Quando um 777 resolve, a causa real era outra: dono errado (resolva com chown), pasta sem x no caminho (resolva com 755 nas pastas) ou arquivo sem leitura para o processo certo (644 resolve). Identifique qual dos três é o seu caso e aplique o valor mínimo.

Chave SSH recusada. Ao conectar, o cliente mostra WARNING: UNPROTECTED PRIVATE KEY FILE! e algo como Permissions 0644 for id_ed25519 are too open, e ignora a chave. É proteção proposital: chave privada legível por outros usuários deixou de ser privada. Corrija com chmod 600 ~/.ssh/id_ed25519 e chmod 700 ~/.ssh. No servidor de destino, o authorized_keys em 600 e o home sem escrita de grupo também contam para o sshd aceitar o login por chave.

Script que não roda. O erro Permission denied ao chamar ./script.sh quase sempre é a falta do bit x. Um chmod u+x script.sh resolve. Se o arquivo veio de um zip ou de um download, ele costuma chegar sem execução, porque formatos como o zip nem sempre preservam permissões Unix.

Montagens do Windows e WSL. NTFS, FAT e exFAT não armazenam permissões POSIX. No WSL, os arquivos em /mnt/c aparecem como 777 e o chmod não muda nada, a menos que a montagem tenha a opção metadata configurada no /etc/wsl.conf. O mesmo vale para pendrives e HDs externos formatados para Windows montados no Linux: a permissão exibida é definida pelas opções de montagem, não pelo chmod. Se o projeto depende de permissões corretas (chaves SSH, scripts, git), mantenha os arquivos no sistema de arquivos nativo do Linux.

Vale lembrar que permissões clássicas são uma parte do controle de acesso. Existem também as ACLs (comandos getfacl e setfacl), que permitem regras por usuário específico, e módulos como SELinux e AppArmor por cima de tudo. Para o dia a dia, porém, rwx, as três classes, os bits especiais e a umask cobrem a grande maioria dos casos.

Quando usar a ferramenta do ValorFinal

Use as ferramentas DevOps para marcar as permissões e obter o octal e o simbólico na hora, além de validar ARN da AWS e gerar hash de arquivo. Para cálculo de redes, veja a calculadora de sub-rede IPv4. Conheça as demais ferramentas de tecnologia.

Fontes oficiais

• man chmod (Linux man-pages): referência das opções e da sintaxe no Linux.
• POSIX chmod (The Open Group): especificação do comando e da notação simbólica.
• GNU coreutils (chmod): documentação oficial da implementação usada nas distros Linux.

Conclusão

Permissões no Linux se resumem a rwx para dono, grupo e outros, somados em octal (4+2+1). Saber que 755, 644 e 600 cobrem a maioria dos casos, que o X maiúsculo salva o chmod recursivo, que setgid e sticky bit resolvem pastas de equipe e /tmp, e que 777 é um risco evita tanto erros de acesso quanto brechas de segurança. Para montar e ler permissões na prática, use as ferramentas DevOps e conheça as demais ferramentas de tecnologia.