Cerramos el Módulo 4 con una lista de deudas, y esta lección salda la primera y la más incómoda: svc-tramontana existe «por arte de magia» y el grupo tramontana no existe en absoluto. Has estado escribiendo chown svc-tramontana:tramontana sobre ficheros cuyo grupo nadie había creado nunca. Eso hoy se acaba. Vas a ver qué es de verdad una identidad en Linux —un número, no un nombre—, qué ficheros son la fuente de la verdad y qué contiene cada campo, cómo se crean cuentas de persona y cuentas de servicio (que no se parecen en nada), y por qué el error más caro de todo el módulo cabe en una letra que falta: usermod -G en lugar de usermod -aG.

1. El modelo de identidad: UID, GID y grupos suplementarios
2. Los cuatro ficheros de la verdad, campo a campo
3. Tipos de cuenta y el rango de UID de /etc/login.defs
4. Crear usuarios: useradd, adduser y /etc/skel
5. Contraseñas: fijar, bloquear y el significado de ! y *
6. Modificar y borrar cuentas, y los ficheros huérfanos
7. Caducidad de cuentas con chage
8. Grupos: crear, modificar y por qué hay que reabrir sesión
9. Cuentas de servicio: por qué la app nunca corre como root
10. Auditoría: quién es quién y quién ha entrado
11. Caso Tramontana: saldar la deuda del módulo anterior

El kernel no sabe qué es operador. El kernel solo maneja números:

• UID (User ID): identifica al usuario. El propietario de un fichero es un número guardado en el inodo, no una cadena.
• GID (Group ID): identifica un grupo. Cada usuario tiene un grupo primario (el que hereda un fichero nuevo que crea) y cero o más grupos suplementarios.

Los nombres solo existen para nuestra comodidad, y la traducción número→nombre la hace la librería del sistema leyendo /etc/passwd y /etc/group. Por eso, si borras un usuario, ls -l empieza a mostrar números crudos: el fichero conserva el UID 1003 aunque ya nadie se llame así.

Léelo así: operador es el 1000, su grupo primario es operador (1000) y pertenece además a adm y sudo como suplementarios. Esa distinción importa:

El primario se define en el campo 4 de /etc/passwd y es el que se asigna a los ficheros que el usuario crea; los suplementarios se definen en el campo 4 de /etc/group y solo amplían el acceso. El grupo efectivo de un proceso puede cambiarse en caliente con newgrp o sg.

En Ubuntu, por defecto cada usuario recibe un grupo propio con su mismo nombre (esquema UPG, User Private Group). No es capricho: permite trabajar con umask 002 sin exponer los ficheros a media máquina, porque «el grupo» es solo tú.

Siete campos separados por :. Es legible por todo el mundo (644) porque cualquier proceso necesita traducir UID a nombre para un simple ls -l.

Nueve campos. Permisos 640, propiedad root:shadow: legible por root y por el grupo shadow, invisible para el resto. Ahí está el hash, y un hash legible por cualquiera es un hash que alguien acabará rompiendo con una GPU.

El hash tiene formato $id$parámetros$sal$hash. En Ubuntu 24.04 el algoritmo por defecto es yescrypt ($y$), que sustituyó a SHA-512 ($6$) por ser resistente a ataques con GPU y ASIC gracias a su coste en memoria:

Cuatro campos: nombre, contraseña (x), GID y lista de miembros suplementarios. Ojo: quien tenga ese grupo como primario no aparece en esa lista. /etc/gshadow (640, root:shadow) guarda la contraseña del grupo —una rareza que casi nadie usa— y los administradores del grupo, que pueden añadir miembros con gpasswd sin ser root.

Quien decide esos rangos es /etc/login.defs:

Lo importante: UID 0 es root no por el nombre, sino por el número. Si creas una segunda cuenta con UID 0, tienes dos roots y ninguna auditoría que los distinga en el inodo. Nunca lo hagas.

useradd es la herramienta de bajo nivel de la suite shadow: hace exactamente lo que le pides, ni una cosa más. Sus opciones clave:

adduser es un script en Perl de Debian que envuelve a useradd y hace lo que un humano espera: elige el UID libre, crea el home con permisos correctos, crea el grupo propio, copia /etc/skel, pregunta la contraseña y rellena el GECOS de forma interactiva. Comparación honesta:

Regla práctica: a mano, adduser; en un script, useradd, porque su comportamiento no depende de un fichero de configuración distribuido.

/etc/skel (que en Ubuntu contiene .bashrc, .profile y .bash_logout) es la plantilla del home: todo lo que hay dentro se copia al crear la cuenta con -m. Es el sitio para imponer un .bashrc corporativo o el prompt rojo de producción del Módulo 3.

Bloquear y desbloquear:

La L de passwd -S es «locked»; P sería contraseña utilizable y NP sin contraseña, que es una emergencia.

usermod -L hace lo mismo que passwd -l sobre el hash. La diferencia práctica no está entre ellos, sino en lo que ninguno de los dos hace: bloquear la contraseña no impide entrar por clave SSH, ni mata las sesiones abiertas. Para una baja de personal de verdad hace falta la combinación completa:

-e 1 fija la caducidad al 2 de enero de 1970: la cuenta queda expirada y PAM rechaza el acceso venga por donde venga.

usermod cambia lo que ya existe. Y aquí está el error clásico del módulo:

Sin la -a (append), operador sale de sudo y de adm en el mismo instante. Si además la sesión root estaba cerrada, acabas de perder la administración de la máquina y toca arrancar en modo de recuperación. Comprueba siempre antes y después con id.

Otros usos habituales:

Borrar:

userdel -r no encuentra lo que el usuario dejó fuera de su home: un fichero en /srv, un cron, un temporal. Esos ficheros quedan con un UID sin nombre y, peor aún, el siguiente usuario que reciba ese UID heredará su propiedad. Auditoría obligatoria antes de reasignar:

Aviso de cumplimiento. Las altas y bajas de personal no son una tarea técnica aislada: en un entorno real deben seguir un procedimiento aprobado (quién autoriza, en qué plazo se revoca el acceso, qué se hace con los ficheros del empleado, que pueden contener datos personales de huéspedes). Documenta cada alta y cada baja con fecha y autorizante, y que el responsable de seguridad o de cumplimiento (RGPD) valide el procedimiento antes de aplicarlo.

chage maneja los campos 3 a 8 de /etc/shadow sin que tengas que contar días desde 1970.

La política de contraseñas de verdad —longitud mínima, complejidad, diccionario, historial— no vive aquí: la impone PAM con pam_pwquality, y es materia de 06-06. chage solo pone los plazos.

gpasswd -a y usermod -aG hacen lo mismo; gpasswd tiene la ventaja de no admitir el error de la -a olvidada, porque su sintaxis siempre es aditiva.

Y ahora el detalle que hace perder tardes enteras: añadir a alguien a un grupo no afecta a sus sesiones abiertas.

La razón es que los grupos suplementarios se fijan en el momento del login, quedan grabados en las credenciales del proceso y se heredan a los hijos. Ningún fichero de configuración va a cambiar un proceso que ya está corriendo. Las salidas:

Lo correcto es cerrar la sesión y volver a entrar. Y lo mismo vale para los servicios: si cambias los grupos de svc-tramontana, hay que reiniciar el servicio, no basta con recargar.

Una aplicación expuesta en el puerto 8080 es la puerta de entrada más probable a tu servidor. Si corre como root, cualquier fallo de ejecución remota es game over: la máquina entera. Si corre como svc-tramontana, el atacante hereda una identidad que no puede leer /etc/shadow, no puede escribir en /etc, no puede instalar nada y no puede leer los ficheros de otros usuarios.

Lo que distingue a una cuenta de servicio:

• UID de sistema (-r, por debajo de 1000) y sin caducidad: una cuenta de servicio que caduca tumba el servicio a las 3 de la madrugada.
• Sin shell de login: /usr/sbin/nologin (imprime un mensaje y sale con error) o /bin/false.
• Sin contraseña utilizable (! o * en shadow) y sin home propio: normalmente apunta al directorio de la aplicación.

getent es siempre preferible a grep /etc/passwd: el día que la empresa añada un directorio corporativo, grep mentirá y getent seguirá diciendo la verdad.

Estado de partida en srv-tramontana: operador (1000) y luis (1001) existen; svc-tramontana y el grupo tramontana no, aunque medio módulo hablaba de ellos. Lo arreglamos en orden, y con copia previa de los ficheros de identidad tal como manda la convención del curso.

-M impide crear el home: /opt/tramontana ya existe y no queremos que useradd le vuelque /etc/skel encima. Verificamos antes de tocar nada más:

Ahora la propiedad de los directorios, que hasta hoy era una promesa:

Fíjate en el o=: nadie fuera del grupo ve nada, aplicando la convención de «grupo compartido en vez de permisos a otros». Ese 2 de 2770 en uploads es el bit SGID, que hace que todo lo que se cree dentro pertenezca al grupo tramontana sin depender de quién lo cree; lo desmenuzamos en la lección siguiente.

Y la documentación, que es parte del trabajo:

• usermod -G sin -a. El error más caro de la lección: sustituye la lista entera y puede sacarte de sudo. Antes de tocar grupos, guarda la salida de id usuario; después, compárala.
• Esperar que un grupo nuevo funcione en la sesión actual. No pasará. id usuario consulta la base de datos, id a secas consulta tu sesión. Cierra y abre sesión, y reinicia los servicios afectados.
• Editar /etc/passwd o /etc/shadow con nano. Usa vipw y vipw -s (y vigr para los grupos): bloquean el fichero y validan la sintaxis al salir. Un shadow corrupto es un servidor donde no entra nadie.
• Crear la cuenta de servicio con shell. Si svc-tramontana tiene /bin/bash, cualquier vía que consiga ejecutar como él consigue una shell interactiva. nologin no es cosmética.
• Confundir bloquear con deshabilitar. passwd -l no impide el acceso por clave SSH. Para una baja: usermod -L -e 1 -s /usr/sbin/nologin y pkill -u. Y no reutilices el UID de una cuenta borrada sin auditar antes con find -uid.
• Consejo: fija los UID y GID de servicio (997, 1002) explícitamente y anótalos. El día que restaures una copia en otra máquina, los números tienen que coincidir o los permisos se descolocarán en bloque.

1. Alta completa de un becario. Crea la cuenta becario con useradd: home propio, shell Bash, GECOS «Becario Operaciones», miembro suplementario de tramontana, contraseña que deba cambiar en el primer acceso y caducidad de la cuenta el 31 de diciembre de 2026. Verifica todo sin abrir sesión con ella.
2. Diagnóstico de un desastre. Alguien ha ejecutado sudo usermod -G tramontana operador. Describe el síntoma exacto que verá operador en su siguiente inicio de sesión, cómo lo confirmarías y cómo lo reparas si ya no tienes sudo.
3. Auditoría de cuentas. Escribe un comando que liste, a partir de /etc/passwd, únicamente las cuentas de persona (UID ≥ 1000, excluyendo nobody) con su shell, y otro que detecte cuentas con contraseña vacía en /etc/shadow.

1.

Aquí -G sin -a es correcto, porque la cuenta se está creando y no hay grupos previos que perder. La -a solo importa en usermod.

2. El síntoma: operador inicia sesión con normalidad, pero cualquier sudo responde operador is not in the sudoers file. This incident will be reported., y además pierde el acceso de lectura a los logs que le daba adm. Confirmación:

Faltan 4(adm) y 27(sudo). Reparación con privilegios: sudo usermod -aG adm,sudo operador y reabrir sesión. Sin sudo y sin otra cuenta administradora, no hay atajo desde dentro: hay que reiniciar la VM, editar la entrada de GRUB para arrancar con init=/bin/bash, remontar la raíz con mount -o remount,rw / y ejecutar usermod -aG adm,sudo operador. Ese procedimiento de recuperación se ve a fondo en 07-01; que exista es precisamente la razón de que el acceso físico o a la consola de la VM sea, en sí mismo, acceso de administrador.

3.

Silencio en la salida significa que no hay ninguna, que es exactamente lo que quieres ver: la convención de «silencio si todo va bien» aplicada a una auditoría.

Ya no queda magia en las identidades de srv-tramontana. Sabes que un usuario es un número; lees los nueve campos de /etc/shadow, reconoces un hash $y$ de yescrypt y distingues !, * y el campo vacío; separas cuentas de sistema de cuentas de persona por el rango de UID de /etc/login.defs; creas cuentas con useradd en scripts y con adduser a mano, sabiendo qué aporta /etc/skel; fijas plazos con chage y dejas la política de contraseñas para 06-06; y has interiorizado que usermod -G sin -a es una forma rápida de perder la máquina y que un grupo nuevo no existe hasta que se reabre la sesión.

Y, sobre todo, has saldado la deuda: el grupo tramontana (gid 1002) existe, svc-tramontana (uid 997) es una cuenta de sistema real sin shell ni contraseña, operador y luis están en el grupo, /opt/tramontana y /srv/tramontana/backups tienen dueño y el cambio está anotado en el HISTORIAL.

Falta la otra mitad de la ecuación. Tienes identidades, pero sudo sigue siendo una palabra mágica que escribes sin saber quién decide qué te permite hacer, y los bits raros que viste de refilón en 02-07 —esa s en lugar de la x— siguen sin explicación, aunque acabas de usar uno al poner 2770 en uploads. En la lección siguiente, sudo y Permisos Especiales, se acaban las dos cosas: escribirás una regla de sudoers que permita a operador reiniciar y desplegar la aplicación sin ser root, entenderás SUID, SGID y el sticky bit de verdad, sustituirás un SUID por capabilities para que la app pueda escuchar en el puerto 80, y darás a Luis acceso a los logs con una ACL sin meterlo en el grupo adm.