Usuários, grupos e permissões no Linux

1. Fundamentos de Usuários e Grupos no Linux

1.1. Conceitos de UID, GID e o arquivo /etc/passwd

No Linux, cada usuário é identificado por um User ID (UID) numérico e cada grupo por um Group ID (GID). O arquivo /etc/passwd armazena informações básicas dos usuários:

root:x:0:0:root:/root:/bin/bash
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
appuser:x:1001:1001:Application User:/home/appuser:/usr/sbin/nologin

Cada linha contém: usuário:senha:UID:GID:descrição:diretório_home:shell. O campo de senha atualmente armazena apenas um x, indicando que a senha real está em /etc/shadow.

O UID 0 é reservado para root. UIDs de 1 a 999 são para usuários de sistema (serviços), e UIDs >= 1000 são para usuários comuns.

1.2. Gerenciamento de usuários: useradd, usermod, userdel

# Criar usuário com diretório home e shell específico
useradd -m -d /home/devops -s /bin/bash devops

# Definir senha
passwd devops

# Modificar UID e adicionar a grupos suplementares
usermod -u 2000 -G docker,sudo devops

# Remover usuário e seu diretório home
userdel -r devops

1.3. Gerenciamento de grupos: groupadd, groupmod, groupdel e o arquivo /etc/group

O arquivo /etc/group define os grupos e seus membros:

docker:x:999:jenkins,devops
developers:x:1002:alice,bob,charlie

Comandos práticos:

# Criar grupo
groupadd -g 1500 developers

# Adicionar usuário a um grupo
usermod -aG developers alice

# Modificar GID de um grupo
groupmod -g 2500 developers

# Remover grupo
groupdel developers

2. Permissões Tradicionais: Leitura, Escrita e Execução

2.1. Entendendo a máscara de permissões (rwx) e o comando chmod

As permissões são divididas em três níveis: dono (user), grupo (group) e outros (others). Cada nível pode ter permissões de leitura (r=4), escrita (w=2) e execução (x=1).

-rw-r--r--  1 devops developers  1024 Jan 15 10:00 script.sh

Interpretação: - (arquivo comum), rw- (dono: leitura+escrita), r-- (grupo: apenas leitura), r-- (outros: apenas leitura).

2.2. Permissões em modo simbólico vs. octal

Modo simbólico:

# Adicionar execução para dono e grupo
chmod ug+x script.sh

# Remover escrita para outros
chmod o-w script.sh

# Definir permissões exatas
chmod u=rwx,g=rx,o=r script.sh

Modo octal (mais comum em scripts e Dockerfiles):

# 755: dono=rwx, grupo=rx, outros=rx (comum para scripts executáveis)
chmod 755 script.sh

# 644: dono=rw, grupo=r, outros=r (comum para arquivos de configuração)
chmod 644 config.yaml

# 600: dono=rw apenas (arquivos sensíveis como chaves SSH)
chmod 600 id_rsa

2.3. Dono e grupo de arquivos: chown e chgrp

# Alterar dono de um arquivo
chown jenkins script.sh

# Alterar dono e grupo simultaneamente
chown jenkins:developers script.sh

# Alterar apenas o grupo
chgrp developers script.sh

# Recursivamente em diretórios
chown -R appuser:appgroup /app/data

3. Permissões Especiais: SUID, SGID e Sticky Bit

3.1. SUID (Set User ID)

Quando um binário tem SUID ativado, ele executa com as permissões do dono do arquivo, não do usuário que o executou. Exemplo clássico: /usr/bin/passwd (dono root, SUID ativado).

# Ativar SUID (modo octal 4xxx)
chmod 4755 script.sh

# Verificar: aparece como 's' no lugar de 'x' do dono
ls -la script.sh
-rwsr-xr-x  1 root root 1024 Jan 15 10:00 script.sh

Risco de segurança: SUID em scripts personalizados pode permitir escalonamento de privilégios. Evite em ambientes containers.

3.2. SGID (Set Group ID)

Em diretórios, SGID faz com que novos arquivos herdem o grupo do diretório.

# Ativar SGID em diretório (modo octal 2xxx)
chmod 2775 /shared/project

# Novos arquivos criados dentro herdarão o grupo 'project'
touch /shared/project/newfile.txt
ls -la /shared/project/newfile.txt
-rw-r--r--  1 alice project 0 Jan 15 10:00 newfile.txt

3.3. Sticky Bit: protegendo arquivos em diretórios compartilhados

O Sticky Bit impede que usuários removam arquivos de outros usuários em diretórios compartilhados. Exemplo: /tmp.

# Ativar Sticky Bit (modo octal 1xxx)
chmod 1777 /shared/temp

# Verificar: aparece como 't' no final
ls -la /shared/
drwxrwxrwt  2 root root 4096 Jan 15 10:00 temp

4. Controle de Acesso Avançado com ACLs

4.1. Introdução às Access Control Lists: getfacl e setfacl

ACLs permitem permissões granulares além dos três níveis tradicionais.

# Ver ACLs de um arquivo
getfacl script.sh

# Adicionar permissão de leitura para um usuário específico
setfacl -m u:alice:rx script.sh

# Adicionar permissão para um grupo
setfacl -m g:developers:rwx script.sh

# Remover ACL específica
setfacl -x u:alice script.sh

4.2. Permissões granulares para múltiplos usuários e grupos

# Configurar múltiplas ACLs em um diretório
setfacl -m u:jenkins:rwx,u:alice:rx,g:devops:rwx /app/deploy

# Ver resultado
getfacl /app/deploy
# file: /app/deploy
# owner: root
# group: root
# user::rwx
# user:jenkins:rwx
# user:alice:r-x
# group:devops:rwx
# mask::rwx
# other::---

4.3. Herança de ACLs em diretórios e máscara de permissão

# Definir ACLs padrão (herdadas por novos arquivos)
setfacl -d -m u:jenkins:rwx /app/shared

# Máscara define o máximo efetivo para usuários/grupos nomeados
setfacl -m m::rx /app/shared  # Limita todas as ACLs a rx

5. Usuários e Grupos no Contexto de Docker

5.1. Usuário padrão (root) vs. usuários não-root em containers

Por padrão, containers rodam como root (UID 0). Isso é uma prática insegura.

# Verificar usuário atual no container
docker run alpine id
# uid=0(root) gid=0(root) groups=0(root)

5.2. Boas práticas: USER no Dockerfile e --user no docker run

# Dockerfile seguro
FROM node:18-alpine

# Criar usuário não-root
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Definir proprietário dos arquivos
COPY --chown=appuser:appgroup . /app

# Mudar para usuário não-root
USER appuser

WORKDIR /app
CMD ["node", "server.js"]

Executando com usuário específico:

# Executar container como UID 1001
docker run --user 1001:1001 myapp

# Mapear usuário do host para o container
docker run --user $(id -u):$(id -g) -v $(pwd)/data:/data myapp

5.3. Montagens de volumes e conflitos de UID/GID entre host e container

# Problema: arquivos criados no container com UID 1000 aparecem como UID 1000 no host
# Solução: usar o mesmo UID ou ajustar permissões

# Exemplo com bind mount
docker run -v /host/data:/container/data --user 1000:1000 myapp

# Ajustar permissões após montagem
docker run alpine chown -R 1000:1000 /data

6. Segurança de Permissões em Kubernetes

6.1. SecurityContext: runAsUser, runAsGroup e fsGroup em Pods

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      runAsUser: 1001
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

6.2. Pod Security Policies (PSP) e Pod Security Admission (PSA)

PSA (sucessor do PSP) define níveis de segurança:

# Namespace com política restritiva
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/warn: baseline

6.3. Gerenciamento de ServiceAccounts e RBAC para acesso a recursos

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pipeline-sa
  namespace: ci
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: ci
  name: pod-manager
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "create", "update", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pipeline-binding
  namespace: ci
subjects:
- kind: ServiceAccount
  name: pipeline-sa
  namespace: ci
roleRef:
  kind: Role
  name: pod-manager
  apiGroup: rbac.authorization.k8s.io

7. Ferramentas de Diagnóstico e Troubleshooting

7.1. Identificando problemas de permissão: id, whoami, ls -la

# Verificar identidade atual
whoami
id
id jenkins

# Verificar permissões detalhadas
ls -la /app/config.yaml
stat /app/config.yaml

# Testar acesso
test -r /app/config.yaml && echo "Leitura OK"
test -w /app/config.yaml && echo "Escrita OK"

7.2. Debugando acesso com strace e auditd

# Rastrear chamadas de sistema relacionadas a permissão
strace -e trace=access,openat,chmod chmod 644 /app/config.yaml

# Monitorar eventos de acesso negado com auditd
auditctl -w /etc/shadow -p wa -k shadow_changes
ausearch -k shadow_changes

7.3. Casos comuns em ambientes DevOps: permissão negada em volumes e sockets

# Problema: "Permission denied" ao acessar /var/run/docker.sock
# Solução: adicionar usuário ao grupo docker
usermod -aG docker jenkins

# Problema: volume montado com permissões incorretas
# Debug: verificar UID/GID dentro e fora do container
docker run alpine stat /data
ls -la /host/data  # No host

# Solução: usar fsGroup no Kubernetes ou --user no Docker

8. Automação e Infraestrutura como Código

8.1. Gerenciamento declarativo de usuários/grupos com Ansible

---
- name: Gerenciar usuários e grupos
  hosts: all
  tasks:
    - name: Criar grupo developers
      group:
        name: developers
        gid: 1500
        state: present

    - name: Criar usuário appuser
      user:
        name: appuser
        uid: 1000
        group: developers
        shell: /bin/bash
        create_home: yes
        state: present

    - name: Configurar permissões do diretório /app
      file:
        path: /app
        owner: appuser
        group: developers
        mode: '0750'
        state: directory

8.2. Scripts de bootstrap para criação de usuários em imagens Docker

#!/bin/bash
# bootstrap.sh - Script para Dockerfile

# Criar grupo com GID específico
groupadd -g ${APP_GID:-1000} appgroup

# Criar usuário com UID específico
useradd -m -u ${APP_UID:-1000} -g appgroup -s /bin/bash appuser

# Ajustar permissões de diretórios
chown -R appuser:appgroup /app
chmod 755 /app

8.3. Integração com sistemas de autenticação externa (LDAP, Active Directory)

# Configuração de autenticação LDAP no Linux (nsswitch.conf)
passwd:         files ldap
group:          files ldap
shadow:         files ldap

# Kubernetes: integração com LDAP para RBAC
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ldap-admins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "cn=kubernetes-admins,ou=groups,dc=example,dc=com"

Referências