3
jonas556440
4 min de leitura ·

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ãoLetraValor BinárioValor OctalSignificado em ArquivosSignificado em Diretórios
Readr4 (100)4Pode ler o conteúdoPode listar os arquivos (ls)
Writew2 (010)2Pode modificar/salvarPode criar/apagar arquivos na pasta
Executex1 (001)1Pode executar como binário/scriptPode 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 listar
sudo find /var/www/meu-app -type d -exec chmod 755 {} +

# Arquivos recebem 644 (rw-r--r--) -> Pode ler, mas não executar
sudo 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-project
sudo 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:

Permissa˜o Final=Permissa˜o Base & (∼umask)\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: 0022
umask -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/

Carregando publicação patrocinada...