🔐 Permisos y Ownership (chmod, chown, grupos)

El 80% de errores “Permission denied” en servidores viene de aquí. Esta guía te enseña a leer permisos, entender owner/grupo y corregir accesos sin romper seguridad (evitando el clásico chmod 777).

Básico → Intermedio

Nivel

15–25 min

Lectura

Servidores / EC2

Contexto

Objetivo: que puedas responder rápido: ¿quién tiene acceso?, ¿por qué falla?, ¿qué debo cambiar: chmod o chown?, ¿qué es más seguro?

🧠 Conceptos mínimos (sin humo)

Linux controla acceso con dos piezas: propiedad (owner/grupo) + permisos (r/w/x). Si una de las dos está mal, tu app o tu pipeline va a fallar.

Owner: usuario dueño del archivo/carpeta.
Group: grupo asociado al archivo/carpeta (clave para trabajo en equipo).
Others: cualquier otro usuario que no sea owner ni pertenezca al grupo.
r/w/x:
- r = read (leer)
- w = write (escribir/modificar)
- x = execute (ejecutar / entrar)

👀 Cómo leer permisos (la parte clave)

El comando base para “ver la verdad”:

ls -lah
# -l  formato largo (permisos, owner, grupo, tamaño, fecha)
# -a  incluye archivos ocultos (los que empiezan con .)
# -h  tamaños legibles (K/M/G)

Ejemplos típicos:

-rw-r-----  1 ubuntu  devops  120K Jan 18  app.log
drwxr-x---  2 root    devops  4.0K Jan 18  /opt/app
-rwxr-xr-x  1 ubuntu  ubuntu  2.3K Jan 18  deploy.sh

Primer caracter: - archivo | d directorio
Luego 9 permisos en 3 bloques: rw- (owner) r-- (group) --- (others)
Owner y grupo: en el ejemplo ubuntu devops

Regla mental DevOps:
Antes de tocar nada, corre:

ls -lah
whoami
id

Así sabes: quién eres, qué grupos tienes, y qué permisos existen.

📁 Regla de oro en carpetas (esto confunde a todos)

En directorios, r/w/x significan algo distinto:

r = listar contenido (ls)
x = entrar/atravesar (cd) y “pasar por el directorio”
w = crear/borrar dentro

Caso real: si una carpeta tiene r pero no x, puedes “ver” nombres, pero no puedes entrar ni acceder a archivos dentro.

🛠 chmod (cambiar permisos) – modo claro para novatos

Hay dos estilos: simbólico (legible) y numérico (rápido). En DevOps usarás ambos.

✅ Forma simbólica (muy recomendable al inicio)

Aquí indicas a quién afecta: u (owner), g (group), o (others), a (all).

chmod u+rwx archivo      # u = owner
chmod g+rx carpeta       # g = group
chmod o-r archivo        # o = others
chmod a+r archivo        # a = all (todos)

⚡ Forma numérica (la más usada en servidores)

Valores:

r=4, w=2, x=1
Se suman por cada bloque (owner / group / others)

chmod 644 archivo   # owner rw- (6), group r-- (4), others r-- (4)
chmod 600 secret    # owner rw-, nadie más (ideal para llaves/credenciales)
chmod 755 script.sh # owner rwx, group rx, others rx (script ejecutable común)
chmod 750 /opt/app  # owner rwx, group rx, others nada (seguro en servidores)

Tip real: para scripts:

si no tiene x, no ejecuta → verás Permission denied
solución típica: chmod 755 script.sh (o chmod +x)

👤 chown (cambiar owner/grupo) – cuándo usarlo

chmod no arregla ownership. Si el archivo pertenece a otro usuario, aunque pongas permisos, el proceso real puede seguir fallando.

chown ubuntu archivo                 # cambia owner a ubuntu
chown ubuntu:devops archivo          # owner ubuntu y grupo devops
chown -R ubuntu:devops /opt/app      # recursivo (muy usado en despliegues)

Regla rápida:

Si el owner/grupo está mal → usa chown
Si el owner/grupo está bien pero faltan permisos → usa chmod

👥 Grupos (el truco DevOps para compartir sin “777”)

En DevOps, lo normal es que una app o pipeline “trabaje” con un usuario específico (ej: www-data, jenkins, deploy). En lugar de abrir al mundo, defines un grupo y das permisos al grupo.

groups                 # ver tus grupos
id                      # ver uid/gid y grupos

# (como root) agregar usuario a grupo
usermod -aG devops ubuntu

# aplicar grupo a carpeta de la app
chown -R root:devops /opt/app
chmod -R 770 /opt/app

⭐ Permisos especiales (solo lo que sí se usa en la vida real)

setgid en carpetas (para trabajo en equipo)

Hace que todo lo nuevo herede el grupo del directorio. Esto evita que un archivo nuevo termine con un grupo incorrecto y “rompa” el acceso.

chmod g+s /opt/app
# verás una "s" en el bloque de grupo al listar

Sticky bit (típico en /tmp)

Permite que varios usuarios escriban en la carpeta, pero evita que borren archivos ajenos. Por eso /tmp suele tener sticky bit.

chmod +t /tmp

☁️ Aplicación real en AWS / DevOps (casos típicos)

Nginx/Apache no lee archivos: revisa permisos de directorios + owner del archivo (web user: www-data).
Pipeline copia artefactos pero “permission denied”: carpeta destino pertenece a root → chown o grupo.
App escribe logs y falla: carpeta /var/log/app sin w para el usuario correcto.
Script no ejecuta: falta x → chmod +x o chmod 755.

✅ Takeaways (lo que debes recordar)

ls -lah primero: ahí está la verdad (owner/grupo/permisos).
En carpetas, x es “entrar/atravesar”. Sin x, no avanzas.
No uses 777. Usa grupos + 770/750 y setgid si es compartido.
chown arregla pertenencia; chmod arregla permisos.

🧪 Reto práctico (10–15 min) – “Permission Denied Lab”

Situación real: tu pipeline (usuario deploy) intenta escribir logs en una carpeta creada por provisioning (root), y falla con Permission denied.

Dónde hacerlo: usa /tmp para no dañar tu sistema.
Requisitos: Linux / WSL / VM / EC2. Si estás en EC2, funciona igual.

1) Crear estructura de app

# 1) Crea carpetas típicas de una app
mkdir -p /tmp/perm-lab/app/{bin,logs,config}
cd /tmp/perm-lab

# 2) Crea un "script" de arranque de ejemplo
cat > /tmp/perm-lab/app/bin/start.sh << 'EOF'
#!/bin/bash
echo "App started at $(date)" >> /tmp/perm-lab/app/logs/app.log
echo "OK"
EOF

# 3) Mira cómo quedó
ls -lah /tmp/perm-lab/app/bin
ls -lah /tmp/perm-lab/app/logs

2) Simular el problema (carpetas “de root”)

# Simula que provisioning creó todo como root
sudo chown -R root:root /tmp/perm-lab/app
sudo chmod -R 700 /tmp/perm-lab/app

# Intenta ejecutar como tu usuario actual (fallará)
bash /tmp/perm-lab/app/bin/start.sh

Deberías ver algo como:

Permission denied

3) Diagnóstico (aprende a pensar DevOps)

whoami
id
ls -lah /tmp/perm-lab/app
ls -lah /tmp/perm-lab/app/bin
ls -lah /tmp/perm-lab/app/logs

Preguntas clave:

¿Quién es el owner de start.sh?
¿El script tiene permiso de ejecución?
¿La carpeta logs/ permite escribir?

👀 Ver solución correcta (sin 777) + explicación

✅ Solución profesional: asignar un grupo (ej: devops) y dar permisos al grupo, para que el proceso (deploy/pipeline) pueda operar sin abrir al mundo.

# 1) Crea grupo devops si no existe (no rompe si ya existe)
sudo groupadd devops 2>/dev/null || true

# 2) Agrega tu usuario al grupo devops
sudo usermod -aG devops "$USER"

# 3) Cambia el grupo de la carpeta a devops (root sigue como owner)
sudo chown -R root:devops /tmp/perm-lab/app

# 4) Permite acceso completo al grupo (owner y group), nada para others
sudo chmod -R 770 /tmp/perm-lab/app

# 5) Asegura herencia de grupo para nuevos archivos (setgid)
sudo chmod g+s /tmp/perm-lab/app /tmp/perm-lab/app/logs

# 6) Haz ejecutable el script (por si se quedó sin x)
sudo chmod 770 /tmp/perm-lab/app/bin/start.sh

# 7) Reintenta
bash /tmp/perm-lab/app/bin/start.sh

# 8) Verifica el log
cat /tmp/perm-lab/app/logs/app.log

🔍 ¿Por qué funciona?

El script ahora tiene x (ejecución).
La carpeta logs tiene permisos de escritura para el grupo.
Otros usuarios del sistema no obtienen acceso (no hay 777).
Con setgid, cualquier archivo nuevo se mantiene en el grupo correcto.

Nota: si no ves efecto inmediato tras agregarte al grupo, abre una nueva terminal o ejecuta:

newgrp devops