Permisos en Linux: cómo usar chmod y chown correctamente

En el artículo anterior aprendimos los comandos básicos de Linux. Ahora abordaremos el fundamento de la seguridad: el modelo de permisos. Comprender chmod, chown, los grupos y los bits especiales permite diseñar sistemas donde los scripts no destruyan los archivos de registro y un ataque a una aplicación web no otorgue privilegios de root al atacante. A continuación — una guía detallada, práctica y clara, pensada tanto para principiantes como para quienes automatizan despliegues en cientos de servidores.

¿Para qué sirven los permisos?

Cualquier objeto del sistema de archivos tiene datos y metadatos. Los permisos cumplen cuatro funciones clave:

Confidencialidad — solo tienen acceso los autorizados.
Integridad — un script erróneo no sobrescribirá la configuración a la que no tiene permisos.
Aislamiento — comprometer un servicio no implica la compromisión de todo el sistema operativo.
Auditoría — es fácil identificar al propietario del recurso y a quién contactar en caso de incidente.

Sin permisos estrictos, la canalización DevOps se convierte en un campo minado: umask 000 en un paso del CI/CD — y los artefactos privados pueden ser leídos desde el contenedor por cualquier usuario.

Usuarios y grupos: fundamentos del modelo de seguridad

Linux asocia procesos con identificadores numéricos:

UID (identificador de usuario) — propietario del proceso o del archivo.
GID (identificador de grupo) — grupo principal del propietario.
Grupos suplementarios — lista que amplía el acceso sin cambiar el propietario.

La información se guarda en /etc/passwd y /etc/group. El UID 0 es root; los demás se dividen en cuentas del sistema (usualmente 1–999) y cuentas normales (1000+). Cada proceso hijo hereda el UID/GID del padre, salvo que el código invoque setuid()/setgid().

Tres conjuntos de permisos y nueve bits clásicos

Cada archivo o directorio almacena 12 bits de permisos. Los primeros nueve se distribuyen en tres categorías:

Usuario (u) — propietario.
Grupo (g) — usuarios que forman parte del grupo principal del archivo.
Otros (o) — todas las demás cuentas.

Las acciones se codifican con valores: read = 4, write = 2, execute = 1. La suma de los tres números para cada categoría forma una «puntuación» de 0 a 7:

rw- = 6 — lectura y escritura;
r-x = 5 — lectura y ejecución;
--- = 0 — sin permisos.

El comando ls -l las muestra en formato legible:

-rwxr-x--- 1 alice devops 12288 Apr 30 10:41 deploy.sh
|   | |  |
|   | |  ----> propietario del grupo
|   | -------> propietario (usuario)
|   ----------> permisos (u rwx, g r-x, o ---)
--------------> tipo (- archivo, d directorio, l enlace)

chmod: asignar y cambiar permisos

Forma octal (numérica)

Se utiliza en scripts, playbooks de Ansible, Dockerfile:

chmod 640 secrets.yml   # propietario rw-, grupo r--, otros ---
chmod 0755 /usr/local/bin/tool   # 0 — no tocamos bits especiales, 755 para ugo

Forma simbólica

Útil en sesión interactiva:

chmod u+x build.sh — permite al propietario ejecutar el script;
chmod g-w,o-rwx *.conf — quita el permiso de escritura al grupo y todos los permisos a los demás;
chmod a=rx public — todos tienen permiso solo de lectura y entrada al directorio.

Tres bits especiales: setuid, setgid, sticky

setuid (4 000) — el proceso se ejecuta con el UID del propietario del archivo. Ejemplo: /usr/bin/passwd, que permite a usuarios normales cambiar contraseñas.
setgid (2 000) — equivalente para grupos. En directorios, hace que los nuevos objetos hereden el grupo.
sticky (1 000) — impide eliminar un archivo en un directorio compartido si no eres su propietario. Ejemplo clásico — /tmp.

Para establecer: chmod 4775 script, para quitar: chmod u-s script.

chown y chgrp: cambiar propietario y grupo

Solo root puede asignar archivos a otro usuario, pero cualquier propietario puede cambiar el grupo del objeto si pertenece a él:

sudo chown bob:designers design.psd
sudo chown -R root:admins /srv/api
sudo chgrp marketing report*.odt

Para tareas en lote es útil la opción --reference: chown --reference=/var/www index.html copia el propietario/grupo desde el archivo de referencia.

umask: permisos por defecto

El kernel toma 666 para archivos (777 para directorios) y resta la umask. Con 022 obtenemos 644/755. Verifica tu valor:

$ umask
0022

En la canalización CI establezcan explícitamente umask 027 para que los archivos de registro no sean legibles por todos.

ACL: cuando u-g-o no es suficiente

Las listas de control de acceso (ACL) brindan una granularidad fina:

sudo setfacl -m u:qa:r /var/log/app
getfacl /var/log/app

Las ACL se soportan en ext4, xfs, btrfs e incluso tmpfs. En hosting virtual esto evita el caos cuando decenas de cuentas de servicio deben usar un mismo archivo.

Capacidades de Linux: alternativa moderna al setuid

En lugar de dar UID 0 completo, se puede otorgar al proceso exactamente los privilegios necesarios:

# escuchar 80/443 sin root
sudo setcap cap_net_bind_service+ep /usr/local/bin/myserver

La lista de 40+ capacidades está descrita en man 7 capabilities.

Escenarios prácticos

1. Directorio .ssh seguro

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

OpenSSH rechazará una clave con permisos demasiado abiertos.

2. Desarrollo colaborativo de un sitio

Creamos el grupo www-data e incluimos a nginx y php-fpm.
chown -R root:www-data /var/www/site
chmod 2755 /var/www/site — setgid asegura la herencia del grupo.

3. Restricción de permisos para backup

useradd -r -s /usr/sbin/nologin backup
setfacl -Rm u:backup:rx /etc
setfacl -m default:u:backup:rx /etc

El daemon de backup puede ver las configuraciones pero no modificarlas.

4. Mini-auditoría de setuid innecesarios

#!/usr/bin/env bash
find / -xdev -perm -4000 -type f 2>/dev/null | while read -r f; do
    echo "$(date +%F) SUSPECT $f" >> /var/log/setuid-check.log
done

Errores típicos y cómo evitarlos

chmod 777 "para probar" — bajo carga de producción nadie recordará que era temporal.
Copiar como root — el archivo cambia de propietario; use --preserve=ownership en cp.
Olvidar setgid en un script — el proceso se ejecuta con privilegios de grupo; es preferible usar capacidades.
umask 000 en Dockerfile — cualquier otro contenedor verá el archivo creado.

Lista de verificación al desplegar

Antes de montar discos extraíbles, establezca uid/gid/umask.
Abstraiga roles mediante grupos: web, base de datos, auditoría de registros.
Ejecute find /var/www -type f -perm /g=w,o=w y elimine lo innecesario.
Habilite el perfil SELinux/AppArmor para los servicios si no necesitan acceso al kernel.

Recursos útiles

Conclusiones

El modelo de permisos de Linux se basa en números simples, pero ofrece profundas capacidades: desde los clásicos rwx hasta cap_sys_admin. Al dominar chmod, chown y los grupos, protege la confidencialidad, reduce el daño por vulnerabilidades y facilita el trabajo colaborativo. Convierta el aislamiento en un principio por defecto: el mínimo de permisos — máxima tranquilidad.