En la lección anterior leíste app.log y envios.csv sin problemas, pero antes o después te encontrarás con un Permiso denegado al intentar escribir en /var/log/veloz o al ejecutar tu primer script de ~/veloz-ops/bin. Los permisos no son un obstáculo administrativo: son el mecanismo que impide que un fallo en veloz-api borre los datos de negocio o que cualquier usuario del sistema lea las credenciales de la pasarela de pago. En esta lección aprenderás a leerlos, a modificarlos con criterio y a dejar ~/veloz-ops y /srv/veloz/datos correctamente protegidos.

1. El modelo usuario / grupo / otros
2. Leer la salida de ls -l campo a campo
3. Qué significa x en un fichero y qué significa en un directorio
4. chmod simbólico
5. chmod octal
6. Propiedad: chown, chgrp, id y groups
7. umask: los permisos por defecto
8. Bits especiales: sticky, setgid y setuid
9. sudo y el principio de mínimo privilegio
10. Caso práctico: asegurar el toolkit y los datos de Veloz Envíos

Todo fichero y todo directorio en Linux tiene un propietario (un usuario) y un grupo. A partir de ahí, los permisos se definen para tres clases de sujetos:

Y para cada clase existen tres permisos:

La regla de evaluación es importante y sorprende a mucha gente: el sistema comprueba solo la primera clase que coincide. Si eres el propietario, se aplican los permisos de u y no se miran los de g ni los de o, aunque fueran más permisivos. Un fichero con permisos ----rwxrwx es ilegible para su propietario y accesible para todos los demás.

Los campos, en orden, son: tipo y permisos (-rw-r-----), número de enlaces duros (1, tema de 05-01), propietario (veloz), grupo (veloz), tamaño en bytes (21504), fecha de última modificación y nombre. Lo interesante son los diez primeros caracteres:

• Tipo -: fichero regular. Sería d para un directorio y l para un enlace simbólico.
• u = rw-: el usuario veloz puede leer y escribir, pero no ejecutar.
• g = r--: los miembros del grupo veloz solo pueden leer.
• o = ---: el resto del sistema no puede ni abrirlo.

Ese es exactamente el diseño que queremos para unos datos de negocio: la aplicación escribe, el equipo de operaciones lee, nadie más ve nada.

Esta distinción es la fuente número uno de confusión con los permisos.

En un fichero, x significa «el sistema puede intentar ejecutarlo como programa». Sin x, un script perfectamente escrito falla con bash: ./informe-diario.sh: Permiso denegado.

En un directorio, x significa algo completamente distinto: permiso de atravesarlo. Sin x en un directorio no puedes hacer cd a él, ni acceder a nada de su interior, ni siquiera a ficheros para los que sí tienes permiso de lectura.

De ahí se derivan tres combinaciones que conviene tener claras:

La combinación --x es la que usan las webs para directorios de configuración: sabes acceder si conoces la ruta, pero no puedes explorar. Y la consecuencia práctica más útil: si un permiso de lectura sobre un fichero no funciona, revisa el x de todos los directorios del camino. Basta con que falte en uno para que la ruta entera sea inaccesible.

chmod (change mode) modifica los permisos. En su forma simbólica se lee casi como una frase: chmod [quién][operador][permisos] fichero.

La diferencia entre + y = es crucial: +r añade lectura conservando lo demás, mientras que =r fija los permisos de esa clase exactamente a lectura, eliminando escritura y ejecución si las tenía. Cuando quieras un estado determinista, usa =.

chmod acepta -R para aplicar recursivamente, pero úsalo con cuidado: chmod -R 755 sobre un árbol convierte en ejecutables ficheros de datos que no deberían serlo. Más adelante, con find (05-01), aprenderás a aplicar permisos distintos a ficheros y directorios en una sola pasada.

La forma octal es la que verás en documentación y scripts, porque es compacta y determinista. Cada permiso tiene un valor numérico y se suman:

r vale 4, w vale 2 y x vale 1. Sumando esos valores salen los ocho dígitos posibles:

Se escriben tres dígitos, uno por clase: usuario, grupo, otros. Los casos que cubren el 95 % de la práctica:

Una regla mental rápida para convertir: piensa en rwx como tres interruptores que valen 4, 2 y 1. rw- = 4+2 = 6; r-x = 4+1 = 5; r-- = 4.

Antes de cambiar la propiedad, comprueba quién eres:

id muestra tu usuario, tu grupo principal y todos los grupos secundarios a los que perteneces. groups da la versión corta. Que joan esté en el grupo veloz es lo que le permite leer los ficheros con permisos 640 propiedad de veloz.

Dos notas importantes:

• Cambiar el propietario requiere root. Un usuario normal no puede «regalar» un fichero a otro, porque eso permitiría burlar las cuotas de disco y colar ficheros en el espacio ajeno.
• Cambiar el grupo sí puede hacerlo el propietario, siempre que él mismo pertenezca al grupo de destino.

Añadir un usuario a un grupo se hace con sudo usermod -aG veloz joan. El -a (append) es obligatorio: sin él, usermod reemplaza la lista de grupos secundarios en lugar de añadir, un error clásico que deja a alguien fuera de sudo. Los cambios de grupo no afectan a sesiones ya abiertas: hay que cerrar sesión y volver a entrar.

Cuando creas un fichero, ¿por qué sale con 644 y no con 777? Porque el sistema parte de unos permisos base y les resta los bits indicados en la umask.

El permiso base es 666 (rw-rw-rw-) para ficheros y 777 para directorios; la umask desactiva bits sobre esa base (no resta aritméticamente). Fíjate en que los ficheros nunca nacen ejecutables: su base no incluye x. Eso es deliberado, y por eso hay que hacer chmod +x explícitamente a cada script nuevo.

Se cambia con umask 077, y para que sea permanente se añade a ~/.bashrc (lección 01-02). Cuidado: la umask solo afecta a ficheros creados después; no modifica los existentes.

Además de los nueve bits rwx hay tres bits especiales, que aparecen como un cuarto dígito octal a la izquierda.

Sticky bit (1000) — En un directorio con escritura para todos, impide que un usuario borre ficheros de otro. Es lo que protege /tmp:

ls -ld /tmp muestra drwxrwxrwt. Esa t final es el sticky bit: sin él, cualquier usuario podría borrar los ficheros temporales de los demás. Se aplica con chmod 1777 dir o chmod +t dir.

Setgid (2000) — Sobre un directorio, hace que todo lo que se cree dentro herede el grupo del directorio en lugar del grupo principal de quien lo crea. Es la pieza clave de los directorios compartidos:

La s en la posición de la x del grupo indica setgid. A partir de ahora, cualquier CSV que deje ahí veloz-api o cualquier miembro del equipo pertenecerá al grupo veloz y será legible por todo el equipo sin intervención manual.

Setuid (4000) — Sobre un ejecutable, hace que se ejecute con los privilegios de su propietario, no de quien lo lanza. Es como passwd puede modificar /etc/shadow siendo tú un usuario normal.

Advertencia seria: setuid es un vector de ataque de primer orden. Un ejecutable setuid de root con un fallo de programación entrega el sistema completo. Nunca pongas setuid a un script de shell —muchos sistemas lo ignoran precisamente por eso— y no lo apliques a tus propios programas salvo que sepas exactamente lo que haces. La seguridad en profundidad se trata en 08-03.

sudo ejecuta un comando concreto con privilegios de root, dejando registro en /var/log/auth.log de quién hizo qué y cuándo. Ese rastro es la razón principal por la que se prefiere a iniciar sesión como root.

El principio de mínimo privilegio dice que cada proceso y cada persona debe tener exactamente los permisos que necesita, ni uno más. Traducido a tu día a día:

• Trabaja siempre como usuario normal; usa sudo solo para el comando que lo requiere.
• Evita sudo su - y las sesiones de root prolongadas: se pierde el registro y desaparece la red de seguridad.
• Resuelve los problemas de acceso con grupos, no repartiendo sudo. Que operaciones lea /srv/veloz/datos es un problema de pertenencia al grupo veloz, no de privilegios de administrador.
• Desconfía de chmod 777. Es la respuesta rápida a un Permiso denegado y casi siempre la incorrecta: deja el fichero escribible por cualquier proceso de la máquina. La solución correcta es ajustar el propietario o el grupo.

El razonamiento de cada decisión:

• 755 en el script: necesita x para ejecutarse. No lleva secretos, así que r-x para grupo y otros es inofensivo y facilita que un compañero lo audite.
• 600 en la configuración: en cuanto guarde una clave de API, cualquier permiso de lectura para «otros» equivale a publicarla. 600 es innegociable en ficheros con credenciales.
• 2775 en el directorio: 775 da control al grupo veloz sobre el contenido; el 2 inicial (setgid) garantiza que los ficheros nuevos hereden ese grupo automáticamente.
• 640 en el CSV: el propietario (la aplicación) escribe, el equipo lee, nadie más ve los datos de negocio.

• Responder a un Permiso denegado con chmod 777. Funciona, y abre un agujero. Pregúntate primero quién debería tener acceso y arréglalo con propietario o grupo.
• Olvidar el x de los directorios del camino. Si cat /srv/veloz/datos/envios.csv falla pese a tener permiso de lectura sobre el fichero, comprueba ls -ld /srv y ls -ld /srv/veloz.
• Usar chmod -R 755 sobre un árbol mixto. Convierte en ejecutables ficheros de datos. Aplica permisos distintos a ficheros y directorios (con find, 05-01).
• Confundir +r con =r. El primero añade, el segundo fija el estado exacto.
• usermod -G sin -a. Reemplaza los grupos secundarios en lugar de añadir y puede dejarte fuera de sudo.
• Esperar que un cambio de grupo tenga efecto inmediato. Hay que cerrar la sesión y volver a abrirla.
• Dejar un fichero de credenciales con 644. Es el fallo de seguridad más frecuente y el más fácil de evitar.

Ejercicio 1 — Leer permisos. Interpreta estas tres líneas de ls -l diciendo, para cada una, qué puede hacer el propietario, qué el grupo y qué el resto, y expresa sus permisos en octal:

Ejercicio 2 — El script que no arranca. Has creado ~/veloz-ops/bin/resumen-envios.sh con un editor y al lanzarlo obtienes Permiso denegado. ls -l muestra -rw-rw-r--. Explica la causa, corrígelo de dos formas (simbólica y octal) y justifica por qué el fichero nació sin x.

Ejercicio 3 — Diseñar los permisos de un directorio compartido. El equipo de operaciones (grupo veloz, tres personas) necesita un directorio /srv/veloz/informes donde todos puedan crear informes y leer los de los demás, pero donde nadie pueda borrar el informe de otro y donde los usuarios ajenos al grupo no vean nada. Escribe los comandos y explica cada bit.

Solución al Ejercicio 1

En datos, la s ocupa el lugar de la x del grupo: la x sigue activa (si no lo estuviera se vería una S mayúscula) y además está el bit setgid, que en octal es el 2 inicial.

Solución al Ejercicio 2

Causa: el fichero no tiene el bit x en ninguna clase, así que el kernel se niega a ejecutarlo, aunque su contenido sea un script válido. Por qué nació sin x: los ficheros se crean con permisos base 666 (rw-rw-rw-), sin ejecución en ningún caso, y la umask 022 retira además la escritura de grupo y otros, dejando 644. El sistema nunca marca un fichero como ejecutable por su cuenta: es una decisión consciente que debe tomar una persona, y esa es precisamente la protección.

Solución al Ejercicio 3

Desglose del 3770:

• 770: propietario y grupo veloz tienen rwx (listar, crear, entrar); otros no tienen nada, que cumple el requisito de invisibilidad para usuarios ajenos.
• 3 = 2 + 1, es decir, dos bits especiales a la vez:
  • 2 (setgid): los informes creados dentro pertenecerán al grupo veloz sin importar el grupo principal de quien los cree, así que todo el equipo puede leerlos.
  • 1 (sticky): aunque todos tienen w sobre el directorio, cada usuario solo puede borrar o renombrar sus propios ficheros. Es el mismo mecanismo que protege /tmp.

La T mayúscula final indica sticky bit sin permiso x para otros; si otros tuviera x aparecería una t minúscula. Este directorio es el ejemplo canónico de cómo los bits especiales resuelven un requisito de colaboración que los nueve bits rwx no pueden expresar.

Ya sabes leer una línea de ls -l campo a campo, distinguir el papel del bit x en ficheros y en directorios —la causa oculta de tantos «permiso denegado»—, y modificar permisos tanto en forma simbólica como octal, con los cuatro patrones que resuelven casi todo: 644, 755, 600 y 700. Controlas la propiedad con chown y chgrp, sabes consultar tus grupos con id, entiendes por qué la umask decide los permisos de cada fichero nuevo y conoces los tres bits especiales, incluido el setgid que hace funcionar un directorio compartido de verdad. Y, sobre todo, tienes el criterio: mínimo privilegio, grupos antes que sudo, y nunca 777.

~/veloz-ops queda con su script ejecutable y su configuración blindada a 600, y /srv/veloz/datos con el grupo veloz y herencia automática. La seguridad en profundidad —inyección de comandos, ficheros temporales seguros, gestión de secretos— se aborda en 08-03.

En la lección 02-04 llega la pieza que multiplica todo lo aprendido: la redirección y las tuberías. Aprenderás a separar la salida normal de los errores, a guardar resultados en ficheros, a descartar ruido con /dev/null y a encadenar los filtros del Módulo 2 en cadenas que responden preguntas complejas sobre acceso.log en una sola línea.