Cuando ejecutas un comando, el kernel no sabe quién eres tú. Sabe qué número tienes. Ese número es el UID (User ID), y es la única identidad que el kernel maneja internamente. El nombre de usuario —ana, root, www-data— es una capa de legibilidad que vive en los archivos de texto de /etc; el kernel la ignora por completo. Esta distinción importa: cuando un proceso accede a un fichero, el kernel compara UIDs numéricos, no cadenas de texto. Si cambias el nombre de un usuario sin cambiar su UID, sigue teniendo exactamente los mismos permisos que antes.
Lo mismo aplica a los grupos: cada grupo tiene un GID (Group ID) numérico, y un usuario puede pertenecer a varios grupos simultáneamente. En cualquier momento dado, un proceso tiene un grupo primario (el que aparece en /etc/passwd) y cero o más grupos suplementarios (los que aparece en /etc/group).
El diseño tiene sentido histórico y práctico. Los UIDs bajos —en Debian moderno, el rango 1–999— se reservan para usuarios del sistema: procesos como el servidor web (www-data, UID 33), el gestor de impresoras (lp), o el servicio de red (systemd-network). Estos usuarios existen para que los daemons corran con identidades propias, limitadas, sin privilegios de persona humana. Los usuarios humanos empiezan en UID 1000 por convención (definida en /etc/adduser.conf). Y luego está root, UID 0, el único usuario al que el kernel trata de forma especialmente: si tu UID es 0, la mayoría de las comprobaciones de permisos simplemente no se aplican.
Usar UIDs incorrectos —o copiar ficheros entre sistemas sin sincronizar los UIDs— provoca problemas silenciosos: un fichero que pertenece al UID 1001 en el sistema A puede pertenecer a un usuario completamente distinto en el sistema B si allí ese número está asignado a otra persona.
El archivo /etc/passwd
/etc/passwd es legible por cualquier usuario del sistema y contiene una línea por cada cuenta, con siete campos separados por ::
nombre:x:UID:GID:GECOS:home:shell
El segundo campo es literalmente x en todos los sistemas modernos. Históricamente ahí estaba la contraseña en texto cifrado, pero eso era visible para cualquiera que pudiera leer el archivo. Hace décadas se movió a /etc/shadow, que solo root puede leer. La x es el marcador que indica “busca en shadow”.
El campo GECOS (nombre heredado de un sistema de los años 70) es software libre: normalmente contiene el nombre completo del usuario y datos de contacto, separados a su vez por comas. finger y algunos otros programas lo leen, pero puedes dejarlo vacío sin problema.
El archivo /etc/group
/etc/group tiene cuatro campos:
nombre:password:GID:lista_de_miembros
El campo de password de grupo existe pero rara vez se usa. La lista de miembros son los usuarios que pertenecen a ese grupo como grupo suplementario; el grupo primario de un usuario no aparece listado aquí, sino en /etc/passwd.
Ejemplo completo: inspeccionar las identidades del sistema
# Ver la identidad numérica del usuario actual id # id de un usuario concreto sin necesidad de ser root id ana # Ver las líneas relevantes de /etc/passwd # grep busca por nombre, pero recuerda: el kernel usa el número grep -E '^(root|ana|www-data):' /etc/passwd # Ver los grupos a los que pertenece ana, incluyendo su GID primario grep -E '^(ana|sudo|adm|cdrom):' /etc/group # Comprobar quién es el propietario numérico de un fichero # -n hace que ls muestre UIDs y GIDs en vez de nombres ls -ln /etc/shadow # Confirmar que /etc/shadow no es legible sin privilegios # Este comando debe fallar con "Permission denied" cat /etc/shadow # Ver el UID/GID de un fichero y comparar con /etc/passwd manualmente stat /home/ana
Lo que está pasando en cada paso
id sin argumentos consulta las credenciales del proceso actual —no el fichero de configuración, sino lo que el kernel tiene registrado para este proceso en tiempo de ejecución. La salida muestra uid=, gid= (el grupo primario), y groups= (todos los grupos, incluyendo suplementarios). Cuando ejecutas id ana, el comando lee /etc/passwd y /etc/group para reconstruir esa información; es una operación de lectura de texto, no una consulta al kernel sobre un proceso real.
El grep sobre /etc/passwd muestra la diferencia entre las tres cuentas: root tiene UID y GID 0; www-data tiene UID 33, un número bajo de sistema; ana tiene un UID ≥ 1000. Fíjate en el último campo de cada línea: root tiene /bin/bash como shell, www-data tiene /usr/sbin/nologin —un binario que simplemente rechaza el login— porque ese usuario nunca necesita una sesión interactiva.
ls -ln usa -n (numeric) para que el sistema no intente resolver los UIDs a nombres. Si estás depurando un problema de permisos en un sistema donde los nombres no coinciden entre máquinas, ver los números directamente evita confusiones.
cat /etc/shadow falla con permiso denegado, y eso es correcto. Que /etc/passwd sea legible es intencional: muchos programas necesitan resolver UIDs a nombres. Que /etc/shadow no lo sea es la razón por la que ese diseño existe. En Debian, /etc/shadow pertenece a root y al grupo shadow con permisos 640; los programas que necesitan autenticar (como login o sudo) tienen los privilegios necesarios para leerlo.
stat /home/ana muestra el UID y GID del directorio home directamente desde los metadatos del inodo —sin pasar por resolución de nombres. Si alguna vez copias un home de otro sistema y los permisos “no funcionan”, lo primero que compruebas es si el UID del propietario coincide con el UID del usuario en el sistema de destino.
N° 32