Permissões, Usuários e Grupos no Linux

Artigo 3 —

Módulo 1 · Fundamentos do Terminal e Linux Prof. Ricardo Matos — Dominando DevOps & Cloud em 1 Ano


Por Que Permissões Importam

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.

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.


O Que Vem a Seguir

No próximo artigo serão abordados processos e serviços no Linux — como verificar o que está rodando no sistema, como iniciar e parar serviços com systemctl, e como garantir que um serviço suba automaticamente após uma reinicialização.


Referências para Aprofundamento

Documentação e leitura

Prática

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.

Artigo 3 de 52 · Módulo 1 — Fundamentos do Terminal e Linux Prof. Ricardo Matos · Série Dominando DevOps & Cloud em 1 Ano


you asked

Não precisa corrigir os artigos anteriores, continue com os próximos. mas vc pode verificar se os links existem antes? do bash deu erro ao acessar. Acho q é bem antigo e usa http sem o s e isso dá erro hoje em dia


claude response

Boa observação. Vou verificar os links antes de escrever, para garantir que todos funcionam.

O ambiente de execução não tem acesso à internet — é uma limitação do sandbox, não dos links em si. Os códigos 000 significam que o DNS não resolve daqui, não que os links estejam quebrados.

O que posso fazer é trabalhar com cuidado na escolha dos links: usar apenas domínios consolidados e bem conhecidos (man7.org, digitalocean.com, redhat.com, gnu.org, ss64.com, linuxcommand.org) e evitar qualquer link com http:// sem o s — que era justamente o problema que você identificou no tldp.org e similares. Links do TLDP, por exemplo, ainda usam HTTP puro em muitas páginas e podem dar problema no navegador moderno.

Seguindo com os próximos artigos, já aplicando esse critério.