Em um servidor de produção, múltiplos serviços rodam simultaneamente. O Nginx não deveria conseguir ler os arquivos de configuração do banco de dados. Um script de deploy não deveria ter acesso às chaves privadas de outro serviço. Um usuário de aplicação não deveria conseguir modificar binários do sistema. Por que permissões importam?
O sistema de permissões do Linux é o mecanismo que garante esse isolamento. Entendê-lo não é opcional — é uma habilidade de segurança fundamental que aparecerá repetidamente ao longo de toda a carreira em DevOps.
Lendo as Permissões
Ao executar ls -la, aparece algo como:
-rwxr-xr-- 1 usuario grupo 4096 Mar 10 10:00 script.sh
drwxr-xr-x 2 usuario grupo 4096 Mar 10 09:00 pasta
Aquela sequência de caracteres no início não é aleatória. Cada posição tem um significado preciso.
- r w x r - x r - -
│ │─────│ │─────│ │─────│
│ dono grupo outros
│
└── tipo: - arquivo, d diretório, l link simbólico
Cada grupo de três caracteres representa as permissões de leitura (r), escrita (w) e execução (x) para três entidades distintas: o dono do arquivo, o grupo ao qual pertence, e outros — todos os demais usuários do sistema. Um hífen no lugar de uma letra significa que aquela permissão não está concedida.
Modificando Permissões com chmod
O chmod altera as permissões de um arquivo ou diretório. Há duas formas de usá-lo.
Forma simbólica — mais legível:
chmod +x script.sh # Adiciona permissão de execução para todos
chmod u+w arquivo.txt # Adiciona escrita para o dono (u = user)
chmod g-w arquivo.txt # Remove escrita do grupo (g = group)
chmod o-r arquivo.txt # Remove leitura de outros (o = others)
chmod u+x,g-w script.sh # Múltiplas alterações de uma vez
Forma octal — mais usada em scripts e automações:
Cada permissão tem um valor numérico: r = 4, w = 2, x = 1. Somam-se os valores para cada entidade.
chmod 755 script.sh # dono: rwx(7), grupo: r-x(5), outros: r-x(5)
chmod 644 config.txt # dono: rw-(6), grupo: r--(4), outros: r--(4)
chmod 600 chave.pem # dono: rw-(6), grupo: ---(0), outros: ---(0)
O 600 para arquivos de chave SSH é especialmente importante — o próprio SSH recusa conexão se a chave privada tiver permissões mais abertas que isso.
Modificando Dono e Grupo com chown
# Muda o dono do arquivo
sudo chown usuario arquivo.txt
# Muda dono e grupo ao mesmo tempo
sudo chown usuario:grupo arquivo.txt
# Aplica recursivamente em uma pasta inteira
sudo chown -R usuario:grupo /var/www/html
O -R aplica a mudança recursivamente a todos os arquivos e subdiretórios. Muito usado ao configurar permissões de diretórios de aplicação em servidores.
Usuários e Grupos
Criando e gerenciando usuários:
sudo useradd -m deploy # Cria usuário 'deploy' com home
sudo passwd deploy # Define senha
sudo usermod -aG sudo deploy # Adiciona ao grupo sudo
sudo userdel -r deploy # Remove usuário e home
Criando e gerenciando grupos:
sudo groupadd devops
sudo usermod -aG devops usuario # Adiciona usuário ao grupo
groups usuario # Lista grupos do usuário
Verificando quem está no sistema:
cat /etc/passwd # Lista todos os usuários
cat /etc/group # Lista todos os grupos
whoami # Usuário atual
id # ID do usuário e grupos aos quais pertence
Um Cenário Real: Configurando um Usuário de Deploy
Em ambientes de produção, é prática comum criar um usuário dedicado para realizar deploys — sem senha, acessado apenas por chave SSH, com permissões restritas ao necessário.
# Cria o usuário sem senha interativa
sudo useradd -m -s /bin/bash deploy
# Cria o diretório .ssh para chaves
sudo mkdir -p /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
# Adiciona a chave pública autorizada
sudo nano /home/deploy/.ssh/authorized_keys
# (colar a chave pública aqui)
# Define permissões corretas para o arquivo de chaves
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh
# Permite que deploy escreva apenas no diretório da aplicação
sudo chown -R deploy:deploy /var/www/minha-aplicacao
A partir desse ponto, o sistema de CI/CD pode conectar via SSH com esse usuário e realizar deploys com escopo limitado — sem acesso root, sem risco de modificar o que não deveria.
Referências para Aprofundamento
Documentação e leitura
- Linux File Permissions Explained — DigitalOcean — Explicação detalhada do sistema de permissões com exemplos práticos.
- Understanding Linux File Ownership — Red Hat — Artigo técnico do Red Hat cobrindo
chmod,chowne boas práticas. - The Linux Command Line — Capítulo 9 — Cobre permissões, processos e o ambiente de usuário com profundidade.
Prática
- Over The Wire: Bandit — níveis 5 a 10 — Esses níveis trabalham permissões e propriedade de arquivos diretamente.
- Linux Permissions Calculator — Ferramenta visual para entender a notação octal antes de decorá-la.
Referência rápida
- chmod Reference — ss64.com — Tabela de referência rápida para todas as opções do
chmod. Útil como consulta até que a notação octal se torne natural.
Exercícios
Exercício 1
Decomponha a permissão abaixo. O que cada trecho informa, e quem pode fazer o quê com esse arquivo?
-rwxr-xr-- 1 usuario grupo 4096 Mar 10 10:00 script.sh
Ver resposta
✓ Resposta: O primeiro caractere é o tipo: - indica arquivo comum (seria d para diretório e l para link simbólico). Os nove caracteres seguintes são três blocos de três. O dono tem rwx: lê, escreve e executa. O grupo tem r-x: lê e executa, mas não altera. Outros têm r--: apenas leem. Cada hífen no lugar de uma letra é uma permissão não concedida — nesse caso, outros não podem nem escrever nem executar o script.
Exercício 2
Como o número da notação octal é formado? Traduza chmod 755 e chmod 644 para a sequência rwx equivalente e diga em que tipo de arquivo cada um costuma ser usado.
Ver resposta
✓ Resposta: Cada permissão vale um número — r = 4, w = 2, x = 1 — e os valores são somados separadamente para dono, grupo e outros. Assim:
755 -> rwx r-x r-x (7 = 4+2+1, 5 = 4+1)
644 -> rw- r-- r-- (6 = 4+2, 4 = 4)
755 é o padrão de script ou diretório executável: o dono altera, os demais apenas usam. 644 é o padrão de arquivo de conteúdo ou configuração legível: só o dono escreve, o resto lê.
Exercício 3
Por que uma chave SSH privada recebe chmod 600? O que acontece se ela estiver com permissões mais abertas?
Ver resposta
✓ Resposta: 600 concede leitura e escrita apenas ao dono, e nada a grupo e outros. O próprio SSH verifica esse modo e recusa a conexão se a chave privada estiver mais aberta — ele prefere falhar a usar uma credencial que outras contas da máquina poderiam ler. O risco é concreto: em um servidor compartilhado, uma chave em 644 significa que qualquer usuário do sistema consegue copiar sua identidade sem deixar rastro.
Exercício 4
No cenário do usuário de deploy, por que /home/deploy/.ssh recebe 700 enquanto authorized_keys recebe 600?
Ver resposta
✓ Resposta: No diretório, 700 dá ao dono leitura, escrita e o x que permite atravessá-lo; sem esse x, ninguém mais consegue sequer entrar para chegar aos arquivos de dentro. No arquivo, 600 restringe leitura e escrita ao dono. A razão de fundo é o que o authorized_keys representa: quem consegue escrever nele adiciona a própria chave pública e passa a entrar como deploy. Por isso o SSH também recusa autenticação quando esses modos estão frouxos.
Exercício 5
O que sudo usermod -aG devops usuario faz? E qual o risco concreto de esquecer o -a?
Ver resposta
✓ Resposta: Adiciona usuario ao grupo suplementar devops. O -G define a lista de grupos suplementares e o -a significa append, ou seja, acrescentar à lista existente. Sem o -a, o comando substitui a lista inteira: o usuário sai de todos os grupos que não estiverem escritos naquela linha. Na prática, usermod -G devops usuario costuma remover a conta do grupo sudo e derrubar o acesso administrativo — um erro silencioso, que só aparece na próxima vez que alguém tenta elevar privilégio.
Exercício 6
Por que criar um usuário deploy dedicado, em vez de deixar o sistema de CI/CD conectar como root?
Ver resposta
✓ Resposta: Por causa do escopo do estrago. O deploy é dono apenas de /var/www/minha-aplicacao, entra somente por chave e não tem senha; se a chave usada pelo CI vazar, o alcance do atacante para no diretório da aplicação. Com root não existe essa fronteira: o mesmo vazamento entrega a máquina inteira, incluindo chaves de outros serviços e binários do sistema. É o princípio do mínimo privilégio aplicado à automação — a diferença entre um incidente contido e um servidor perdido.