Permissões Linux a fundo: Chmod octal, a matemática da umask e o perigo real de SUID/SGID

Se você administra servidores Linux ou sobe aplicações em containers, com certeza já esbarrou no clássico problema de permissão negada (Permission denied) ou viu alguém cometer o erro clássico de rodar chmod -R 777 para "fazer funcionar logo".

Neste guia prático, vamos dissecar como o modelo de permissões POSIX funciona na prática, como resolver permissões de servidores web do jeito certo e o funcionamento dos bits especiais que caem direto em certificações (LPIC-1, RHCSA) e testes de segurança.

1. A Estrutura Básica: Os 3 Grupos e a Tabela Octal

Cada arquivo ou diretório no Linux possui 3 níveis de acesso:

1. User (u): O usuário proprietário do arquivo.
2. Group (g): O grupo ao qual o arquivo pertence.
3. Others (o): Qualquer outro usuário autenticado no sistema.

E cada nível combina três operações fundamentais representadas por valores binários somados:

Permissão

Letra

Valor Binário

Valor Octal

Significado em Arquivos

Significado em Diretórios

Read

r

4 (100)

4

Pode ler o conteúdo

Pode listar os arquivos (ls)

Write

w

2 (010)

2

Pode modificar/salvar

Pode criar/apagar arquivos na pasta

Execute

x

1 (001)

1

Pode executar como binário/script

Pode entrar na pasta (cd)

A soma define o número de cada grupo:

• 7 (4+2+1) = rwx (Leitura, Escrita e Execução)
• 6 (4+2+0) = rw- (Leitura e Escrita)
• 5 (4+0+1) = r-x (Leitura e Execução)
• 4 (4+0+0) = r-- (Apenas Leitura)
• 0 (0+0+0) = --- (Nenhum acesso)

2. A Regra de Ouro para Servidores Web (Nginx / Apache / WordPress)

O maior erro de iniciantes é dar chmod -R 777 ou chmod -R 755.

• Se você der 755 em arquivos, eles ganham bit de execução sem necessidade (risco de execução de scripts maliciosos injetados).
• Se você der 644 em pastas, ninguém consegue entrar nelas (cd), quebrando o servidor web na hora (erro HTTP 403 Forbidden).

O padrão da indústria separa pastas (755) de arquivos (644). O comando correto e eficiente usando find (com + para executar em lote sem sobrecarregar o processador) é:

# Define o proprietário do servidor web (ex: www-data ou nginx)sudo chown -R www-data:www-data /var/www/meu-app# Pastas recebem 755 (rwxr-xr-x) -> Pode entrar e listarsudo find /var/www/meu-app -type d -exec chmod 755 {} +# Arquivos recebem 644 (rw-r--r--) -> Pode ler, mas não executarsudo find /var/www/meu-app -type f -exec chmod 644 {} +# Arquivos sensíveis de configuração (ex: .env, wp-config.php)# Devem ser ainda mais restritivos: apenas o dono lê (600 ou 640)chmod 600 /var/www/meu-app/.env

3. Permissões Especiais: O 4º Dígito Octal

Além das permissões convencionais, existem 3 bits especiais que antecedem o octal tradicional (ex: 4755, 2775, 1777):

🔸 SUID — Set User ID (4000 / u+s)

Faz o executável rodar temporariamente com os privilégios do proprietário do arquivo, e não de quem o chamou.

• Exemplo clássico: /usr/bin/passwd. Um usuário comum precisa alterar sua senha no /etc/shadow (que pertence ao root). O binário passwd tem bit SUID ativo (-rwsr-xr-x), permitindo que a escrita ocorra sob a identidade do root durante a execução.
• Como aplicar: chmod u+s /caminho/binario ou chmod 4755 /caminho/binario.

⚠️ Auditoria de Segurança: Para encontrar binários com SUID no seu servidor (porta de entrada para Privilege Escalation se mal configurados):find / -perm -4000 -type f -exec ls -la {} + 2>/dev/null

🔸 SGID — Set Group ID (2000 / g+s)

• Em executáveis: Roda com privilégios do grupo do arquivo.
• Em diretórios (Muito útil em times): Qualquer novo arquivo ou pasta criado dentro desse diretório herdará automaticamente o grupo da pasta-mãe, em vez do grupo primário do usuário que o criou.
• Como aplicar:

# Pasta de deploy compartilhada entre o time 'devs'sudo chown -R deploy:devs /var/shared-projectsudo chmod 2775 /var/shared-project

🔸 Sticky Bit (1000 / +t / o+t)

Em diretórios onde todos têm permissão de escrita (como /tmp), qualquer usuário poderia apagar arquivos de outros. O Sticky Bit impede isso: apenas o dono do arquivo ou o root pode apagar ou renomear o arquivo.

• Como aplicar: chmod +t /tmp ou chmod 1777 /tmp.
• Representação visual no ls -l: drwxrwxrwt.

4. Como a umask Realmente Funciona (A Matemática Binária)

Muita gente aprende que umask é "apenas subtrair da permissão máxima". Na maioria dos casos simples dá o mesmo resultado, mas matematicamente ela funciona através de um operador lógico bitwise NOT + AND:

\text{Permissão Final} = \text{Permissão Base} \ \& \ (\sim \text{umask})

• A base para Diretórios é 777 (rwxrwxrwx).
• A base para Arquivos é 666 (rw-rw-rw-) — o Linux nunca dá permissão de execução x por padrão na criação de arquivos por motivos de segurança.

Se a sua umask for 022 (padrão em quase todas as distros):

• Para uma pasta nova: 777 - 022 = 755 (rwxr-xr-x).
• Para um arquivo novo: 666 - 022 = 644 (rw-r--r--).

Se a sua umask for 027 (mais restritiva, muito usada em servidores de alta segurança):

• Pastas novas nascem com 750 (Outros usuários não entram nem leem).
• Arquivos novos nascem com 640 (Outros usuários não leem).

Para ver a umask atual no seu terminal:

umask # Retorna octal, ex: 0022umask -S # Retorna formato simbólico: u=rwx,g=rx,o=rx

Qual configuração de permissões vocês costumam padronizar nos ambientes de produção de vocês?

Artigo completo e simulador visual de permissões: tecmestre.com.br/calculadora-chmod/

Source