⚡ Em uma frase - Três operações (r, w, x), três categorias (dono, grupo, outros), três comandos (chmod, chown, umask). Dominar essa equação faz 90% dos erros Permission denied desaparecerem.

Permissões de arquivo são a primeira linha de defesa de qualquer sistema Unix-like. Elas determinam quem pode ler um documento, alterar uma configuração ou executar um binário — e configurá-las errado é a causa número um dos erros Permission denied que aparecem em servidores web, volumes Docker e pipelines de integração contínua. Dominar o modelo POSIX continua sendo requisito básico para quem administra servidores, desenvolve software ou apenas toca a linha de comando com frequência.

A boa notícia é que o sistema é mais simples do que parece. Toda a lógica gira em torno de três operações (ler, escrever, executar), três categorias de usuário (dono, grupo, outros) e três comandos principais. A complexidade aparece nas bordas — bits especiais, ACLs e capabilities — e existe justamente para resolver os limites do modelo tradicional.

📖 Como ler a saída do ls -l

A primeira habilidade prática é interpretar o cabeçalho de cada arquivo. Ao rodar ls -l, o terminal devolve algo parecido com isso:

-rwxr-xr-- 1 ana dev 1842 Jun  5 14:22 deploy.sh
drwxr-x--- 2 ana dev 4096 Jun  5 14:20 segredos

O primeiro caractere indica o tipo do objeto. Um traço (-) significa arquivo regular; d representa diretório; l é um symbolic link (link simbólico, atalho para outro caminho); c e b aparecem em dispositivos de caractere e bloco dentro de /dev. Os nove caracteres seguintes formam três blocos de três posições cada — rwx para o dono, rwx para o grupo e rwx para todos os demais. O hífen em qualquer posição indica permissão ausente.

💡 Dica rápida O bit x muda totalmente de sentido entre arquivos e diretórios. Em arquivo, autoriza executar como programa. Em diretório, autoriza entrar com cd e acessar arquivos por nome. É por isso que um diretório com 644 parece "quebrado": sem o x, o sistema bloqueia a navegação mesmo com permissão de leitura.

🔢 chmod, na forma octal e simbólica

O comando chmod (change mode) altera o conjunto de permissões e aceita duas notações intercambiáveis. A octal é a mais comum em scripts de automação porque produz um estado exato e sem ambiguidade. Cada bit tem um valor — r vale 4, w vale 2 e x vale 1 — e a soma representa a permissão de cada categoria.

Assim, chmod 755 deploy.sh significa 7 (4+2+1) para o dono, 5 (4+1) para o grupo e 5 (4+1) para outros, resultando em rwxr-xr-x.

Tabela de bolso — as combinações que cobrem o dia a dia

Octal   Simbólico       Quando usar

700     rwx------     Scripts e binários de uso pessoal

600     rw-------     Arquivos sensíveis (ex.: chave SSH privada)

644     rw-r--r--     Arquivos de leitura pública (HTML, CSS, config)

755     rwxr-xr-x     Diretórios e scripts compartilhados

750     rwxr-x---     Diretórios restritos a um grupo

640     rw-r-----     Logs lidos por administradores

400     r--------     Segredos somente leitura

777     rwxrwxrwx    ⚠️ Praticamente nunca — sinônimo de problema

A notação simbólica é mais segura quando se quer alterar um bit específico sem mexer no resto. A sintaxe é chmod [quem][operador][permissão]: u é o dono, g é o grupo, o são os outros e a engloba todos. O operador + adiciona, - remove e = define exatamente.

chmod u+x script.sh      # adiciona execução para o dono
chmod go-w arquivo.txt   # tira escrita do grupo e dos outros
chmod a=r relatorio.md   # todos só leem, ninguém mais escreve

🚨Atenção A flag -R aplica a mudança recursivamente. Rodar chmod -R 777 em um diretório de produção é um clássico passe livre para escalonamento de privilégios — abre permissão de escrita para qualquer usuário, inclusive em arquivos que o servidor web executa.

👥 chown e umask completam a equação

Mudar permissões resolve só metade do problema. A outra metade é definir o dono e o grupo do arquivo. O comando chown (change owner) aceita o padrão usuario:grupo, e operações típicas em servidores web seguem este formato:

chown -R www-data:www-data /var/www/html   # típico em deploy web
chown :dev arquivo.txt                     # só muda o grupo

O umask define quais bits o sistema remove das permissões padrão sempre que um novo arquivo é criado. A base é 666 para arquivos (sem x por segurança) e 777 para diretórios. Com umask 022, o sistema subtrai 022 dessa base, gerando 644 em arquivos novos e 755 em diretórios novos — exatamente o padrão da maioria das distribuições.

🛡️Curiosidade útil Em servidores que lidam com dados sensíveis, faz sentido subir para umask 077. Isso produz 600 em arquivos e 700 em diretórios, impedindo que algo criado por descuido fique legível para qualquer usuário do sistema.

🔐 Bits especiais, ACL e capabilities

Além das nove permissões básicas, o Linux oferece três bits especiais que aparecem como um quarto dígito octal na frente do número convencional:

🟦 SUID (4xxx) — Faz com que um executável rode com os privilégios do dono do arquivo, não de quem o invocou. É por isso que passwd consegue gravar em /etc/shadow mesmo rodado por um usuário comum.

🟩 SGID (2xxx) — Aplicado a diretórios, força que arquivos criados ali herdem o grupo do diretório-pai. Elimina a necessidade de chgrp constante em pastas compartilhadas por equipes.

🟨 Sticky bit (1xxx) — Visível no /tmp de qualquer sistema. Restringe a exclusão de arquivos dentro de um diretório apenas ao dono de cada arquivo, mesmo quando todo mundo tem permissão de escrita na pasta.

chmod 4755 /usr/local/bin/mytool   # SUID + rwxr-xr-x
chmod 2775 /opt/equipe             # SGID + rwxrwxr-x
chmod 1777 /var/scratch            # sticky + rwxrwxrwx (estilo /tmp)

Quando o modelo "dono, grupo, outros" fica curto, entram em cena as ACLs POSIX. Com setfacl -m u:bruno:rw arquivo.txt é possível conceder leitura e escrita para um usuário adicional sem alterar o grupo do arquivo. ACLs funcionam nativamente em ext4, XFS e Btrfs e resolvem cenários que antes exigiam grupos auxiliares ou cópias paralelas.

A peça mais moderna do quebra-cabeça são as capabilities: fragmentos granulares do privilégio total de root que podem ser atribuídos a binários individuais. Em vez de marcar um serviço com SUID e dar todo o poder de superusuário, é possível conceder apenas o privilégio necessário.

setcap cap_net_bind_service=+ep /usr/local/bin/meuservico
# autoriza abrir portas abaixo de 1024 sem nunca rodar como root

getcap -r / 2>/dev/null
# audita todos os binários do sistema com capabilities definidas

A documentação oficial do kernel descreve 41 capabilities distintas, cobrindo desde manipulação de rede até carregamento de módulos. É a ferramenta certa para substituir SUIDs herdados de código legado.

🎯 O que isso muda

Para o usuário comum: dominar os três comandos básicos elimina praticamente todas as situações de Permission denied no dia a dia. Scripts que não rodam por falta de x, chaves SSH rejeitadas pelo sshd por estarem com 644 em vez de 600, diretórios ~/.ssh que precisam ser 700 para o protocolo aceitar autenticar. A regra de segurança mais útil também é a mais simples: nunca use 777 como atalho para resolver erro de permissão. O caminho correto quase sempre passa por ajustar o dono com chown ou criar um grupo apropriado.

Para administradores e desenvolvedores: o ganho está em substituir hábitos antigos por mecanismos mais finos. Capabilities tornam SUID quase desnecessário em código novo. ACLs eliminam a multiplicação de grupos artificiais. E o umask adequado, definido no perfil do sistema, garante que cada arquivo nasça com a postura de segurança certa, sem depender da disciplina de quem digita o comando. Em uma era em que cada container, microsserviço e pipeline de CI/CD cria e destrói arquivos a todo instante, isso deixou de ser detalhe operacional — virou parte do design da aplicação.

✨ Cheat sheet — os comandos que valem decorar

# ─── Permissões ──────────────────────────────────────
chmod 755 deploy.sh           # rwxr-xr-x
chmod u+x script.sh           # adiciona execução para o dono
chmod -R 644 ./assets/        # recursivo, leitura para todos

# ─── Dono e grupo ────────────────────────────────────
chown ana:dev arquivo.txt
chown -R www-data:www-data /var/www/

# ─── Padrão de criação ───────────────────────────────
umask 022                     # 644 em arquivos, 755 em diretórios
umask 077                     # modo paranoico (600 / 700)

# ─── Bits especiais ──────────────────────────────────
chmod 4755 binario            # SUID
chmod 2775 pasta_equipe/      # SGID
chmod 1777 /var/scratch       # sticky bit

# ─── ACL ─────────────────────────────────────────────
setfacl -m u:bruno:rw arquivo.txt
getfacl arquivo.txt

# ─── Capabilities ────────────────────────────────────
setcap cap_net_bind_service=+ep /usr/local/bin/meuservico
getcap -r / 2>/dev/null       # auditoria geral

# ─── Diagnóstico ─────────────────────────────────────
ls -l arquivo                 # quem é dono, quais bits estão ativos
stat arquivo                  # tudo, em formato verboso
namei -l /caminho/completo    # percorre o caminho mostrando permissões

📚 Fontes

GNU Coreutils Manual

Linux man-pages project

Ubuntu Community Documentation