Permissões, usuários e grupos sem decoreba
Objetivos desta aula
- Ler e escrever permissões em octal e simbólico
- Diferenciar problema de modo e problema de propriedade
- Aplicar propriedade correta em diretórios de aplicação
- Criar usuário de serviço sem shell de login
- Usar sudo com responsabilidade e rastreabilidade
1. As três perguntas de toda permissão
Permissão em Linux responde a: quem (dono, grupo, outros), o que (ler, escrever, executar) e sobre qual objeto. Toda mensagem de permission denied se resolve respondendo essas três perguntas na ordem.
2. Lendo ls -l sem decorar
Em -rw-r----- 1 cloudshop cloudshop 220 app.env: o primeiro caractere é o tipo (- arquivo, d diretório, l link). Depois vêm três blocos de três: dono, grupo, outros. Aqui o dono lê e escreve, o grupo lê, outros nada — ou seja, 640.
3. Octal: 4, 2 e 1
Leitura vale 4, escrita 2, execução 1; soma-se para cada bloco. Então 755 = dono 7 (4+2+1), grupo 5 (4+1), outros 5. E 640 = 6, 4, 0. Com dois minutos de prática isso deixa de exigir consulta.
4. Em diretório, 'x' significa entrar
Essa é a pegadinha mais comum: 644 em pasta impede acessar o conteúdo, mesmo com leitura; é preciso x para atravessar o diretório. Por isso o padrão é 755 (ou 750) em diretórios e 644 (ou 640) em arquivos.
5. Modo simbólico, quando é mais claro
chmod u+x script.sh torna executável para o dono; chmod g-w arquivo remove escrita do grupo; chmod o= arquivo zera o acesso de outros. Em scripts, prefira o octal por ser explícito; na mão, o simbólico erra menos.
6. Propriedade é diferente de modo
A maior parte das falhas reais de deploy é de dono, não de permissão: o processo roda como usuário cloudshop, mas o diretório pertence a root. A correção correta é chown para o usuário do serviço, não distribuir 777 — que é o equivalente a deixar a porta aberta com um aviso de "entre".
7. Usuários e grupos
Grupos existem para compartilhar acesso sem abrir para todos: coloca-se as pessoas (ou serviços) em um grupo e dá permissão ao grupo. id usuario mostra os grupos atuais; usermod -aG grupo usuario adiciona (o -a é obrigatório: sem ele você substitui a lista de grupos). A mudança vale na próxima sessão.
8. Usuário de serviço: menor privilégio na prática
Crie um usuário de sistema sem home e sem shell (--shell /usr/sbin/nologin) para rodar a aplicação. Se a aplicação for comprometida, o invasor herda um usuário que não pode fazer login e não tem acesso a nada além do necessário. Isso é exigência de qualquer auditoria séria.
9. sudo: poder com rastro
sudo executa como outro usuário (normalmente root) e registra quem fez o quê. Boas práticas: nunca compartilhar conta de root, conceder permissões específicas em arquivos dentro de /etc/sudoers.d/, evitar NOPASSWD e jamais dar sudo irrestrito a um usuário de aplicação.
10. umask: as permissões que nascem por padrão
umask é a máscara que define o que é removido das permissões de arquivos novos. Com umask 022, arquivos nascem 644 e diretórios 755. Em servidores que lidam com dados sensíveis, 027 é comum: outros não recebem nada.
11. Bits especiais que aparecem em prova
- setuid/setgid: fazem o programa rodar com o dono/grupo do arquivo — poderoso e perigoso.
- sticky bit (em
/tmp, aparece comodrwxrwxrwt): todos escrevem, mas cada um só apaga o que é seu.
Em auditoria, procurar arquivos com setuid inesperado é rotina de segurança.
12. Roteiro para diagnosticar 'permission denied'
- Qual usuário executa o processo? (
ps -o user= -p PID) - Qual caminho exato ele tentou acessar? (log ou
strace) - Quem é o dono e qual o modo? (
ls -l,stat) - Todos os diretórios do caminho têm
xpara esse usuário? - Teste como o serviço:
sudo -u cloudshop ls /opt/cloudshop.
Na prática
Usuário de serviço e permissões corretas
bash
sudo useradd --system --no-create-home --shell /usr/sbin/nologin cloudshop
sudo mkdir -p /opt/cloudshop /var/log/cloudshop /etc/cloudshop
sudo chown -R cloudshop:cloudshop /opt/cloudshop /var/log/cloudshop
sudo chmod 750 /opt/cloudshop # dono total, grupo entra e le
sudo chmod 640 /etc/cloudshop/app.env
ls -ld /opt/cloudshop # drwxr-x--- cloudshop cloudshop
id cloudshop # uid=997(cloudshop) gid=997(cloudshop)
sudo -u cloudshop ls /opt/cloudshop # testar como o servico enxerga
# auditoria rapida: arquivos graváveis por qualquer usuario
sudo find /opt -perm -o+w -type fNota de segurança: chmod 777 em diretório de aplicação é falha de segurança: qualquer usuário local pode substituir seu binário ou script.
Entendendo octal na prática
bash
cd /tmp && mkdir -p perm-demo && cd perm-demo
echo "ola" > arquivo.txt
ls -l arquivo.txt # -rw-r--r-- = 644 (padrao com umask 022)
chmod 600 arquivo.txt && ls -l arquivo.txt # -rw-------
chmod u+x arquivo.txt && ls -l arquivo.txt # -rwx------ (modo simbolico)
mkdir pasta && chmod 644 pasta
ls pasta # ls: cannot open directory 'pasta': Permission denied
chmod 755 pasta && ls pasta # funciona: diretorio precisa de 'x' para ser atravessado
umask # 0022 -> mostra a mascara atualGrupos e sudo com escopo limitado
bash
sudo groupadd deploy
sudo usermod -aG deploy "$USER" # -a e OBRIGATORIO: sem ele, substitui os grupos
id -nG "$USER" # confira (precisa de nova sessao para valer)
# Permitir apenas reiniciar o servico, sem sudo irrestrito
sudo tee /etc/sudoers.d/deploy-cloudshop >/dev/null <<'EOF'
%deploy ALL=(root) /usr/bin/systemctl restart cloudshop-api, /usr/bin/systemctl status cloudshop-api
EOF
sudo chmod 440 /etc/sudoers.d/deploy-cloudshop
sudo visudo -c # valida a sintaxe: /etc/sudoers.d/deploy-cloudshop: parsed OKNota de segurança: Erro de sintaxe em sudoers pode bloquear o acesso administrativo: valide sempre com visudo -c antes de sair da sessão.
Diagnóstico de permission denied em serviço
bash
systemctl status cloudshop-api --no-pager | tail -5
# Error: EACCES: permission denied, open '/var/log/cloudshop/app.log'
ps -o user=,pid=,cmd= -C node # quem executa o processo -> cloudshop
ls -ld /var/log/cloudshop # drwxr-xr-x root root <- dono errado
sudo chown -R cloudshop:cloudshop /var/log/cloudshop
sudo -u cloudshop touch /var/log/cloudshop/teste # valida como o servico
sudo systemctl restart cloudshop-api && systemctl is-active cloudshop-api # activePor que isso importa
Erros de permissão aparecem como falhas misteriosas de deploy, upload que não grava e serviço que não inicia. Diagnosticar em segundos é diferencial.
Erro comum
Resolver 'permission denied' com chmod -R 777 em vez de corrigir o dono.
Dica de produção
Arquivos com credenciais: 600 ou 640, dono do serviço, e jamais versionados no Git.
Alerta de segurança
Nunca dê sudo sem senha a um usuário de aplicação; se ele for comprometido, o servidor todo cai.
Pergunta de entrevista
Um upload falha com permission denied. Como você investiga em ordem?
Glossário
- umask
- Máscara que define as permissões padrão de arquivos recém-criados.
- usuário de sistema
- Conta sem login interativo, criada para executar serviços.
- chown
- Comando que altera dono e grupo de arquivos e diretórios.
- sudoers
- Configuração que define quem pode executar o quê com privilégio elevado.
- setuid
- Bit que faz um programa executar com a identidade do dono do arquivo.
- sticky bit
- Permissão em diretórios compartilhados que impede apagar arquivos de outros usuários.
- menor privilégio
- Conceder apenas o acesso necessário para a tarefa, reduzindo o dano de um comprometimento.
Conexão com o CloudShop
Criar o usuário cloudshop que executará a API e será dono dos diretórios da aplicação.
Quiz da aula
1. O que significa 750 em um diretório?
2. Por que 644 em um diretório impede listar o conteúdo?
3. Qual é o risco de 'usermod -G deploy usuario' sem o -a?
4. Qual é a melhor prática para rodar a API em um servidor?
Minhas anotações
Salvo automaticamente neste navegador.