2. Usuarios, grupos y por qué existen los permisos

Descripción

Al terminar esta lección vas a poder diagnosticar tu identidad completa frente al sistema operativo con cuatro comandos (whoami, id, groups, who), diferenciar las tres clases de permisos que Unix aplica a cualquier archivo —propietario, grupo y otros— y explicar, con argumentos técnicos y no con superstición, por qué existe una cuenta todopoderosa llamada root y por qué tú no trabajas con ella todos los días.

Esto no es teoría de manual. El día que te conectes por SSH a un servidor de la empresa donde trabajas —compartido con otros nueve desarrolladores— o el día que un contenedor de Docker corra un proceso con un usuario distinto al tuyo, vas a necesitar saber leer quién es cada identidad involucrada. Sin ese modelo, cada Permission denied se siente como un bug aleatorio del sistema, y la reacción instintiva de casi todo junior es "le pongo sudo a todo hasta que funcione" — reacción que en una laptop personal cuesta poco, pero en un servidor compartido de verdad puede sobrescribir el trabajo de otra persona o abrir un hueco de seguridad que alguien más va a pagar.

Conexión con el módulo: la lección anterior mapeó el módulo alrededor de tres errores, y Permission denied fue el primero. Esta lección es la causa raíz de ese error: sin usuarios, sin grupos y sin la existencia de root, no habría nada que un permiso tuviera que proteger. Todavía no vas a tocar chmod ni a descifrar drwxr-xr-x letra por letra —eso es exactamente lo que viene en la siguiente lección—. Hoy el objetivo es entender el modelo antes de tocar el mecanismo.

Tu laptop es un edificio con inquilinos, no una casa vacía

Imagina un edificio de departamentos. Cada inquilino tiene la llave de su propio departamento —y solo la suya—. Los inquilinos del mismo piso comparten una llave adicional para una sala común de ese piso: lavandería, terraza, lo que sea. Y hay una tercera categoría, la más amplia: cualquier otra persona que entre al edificio —un repartidor, una visita— no tiene llave de ningún departamento ni de ninguna sala común, salvo que alguien se la preste. El edificio tiene, además, un superintendente con una llave maestra que abre absolutamente todo. Nadie vive el día a día como superintendente: es una identidad reservada para tareas de mantenimiento puntuales, no para habitar el edificio.

Unix se diseñó en los años setenta exactamente para este escenario, pero con computadoras: mainframes que decenas de personas usaban al mismo tiempo desde terminales distintas. El sistema necesitaba saber, para cada archivo y cada proceso, de quién era y quién más podía tocarlo. Ese diseño multiusuario nunca se abandonó. Aunque hoy seas la única persona sentada frente a tu laptop, el sistema operativo la sigue tratando como si fuera ese edificio: existen múltiples cuentas de usuario ya creadas antes de que tú tocaras el teclado —cuentas de servicio que corren procesos del sistema—, y cada archivo de tu disco pertenece a alguien y a un grupo, exactamente igual que en un servidor con cien usuarios reales.

Tres piezas hacen funcionar ese modelo:

• Usuario: una identidad con un nombre y un número interno (el UID, user ID). El sistema no piensa en nombres, piensa en números — el nombre es solo la etiqueta legible que te muestra.
• Grupo: una colección de usuarios que comparten cierto nivel de acceso. Todo usuario tiene un grupo primario (piensa en el piso del edificio) y puede pertenecer, además, a grupos secundarios (piensa en un club dentro del edificio al que te uniste después: el gimnasio, el estacionamiento).
• root: la cuenta con UID 0. El kernel la reconoce por ese número y, al verlo, se salta las verificaciones de permisos por completo. Es la llave maestra del superintendente — y por la misma razón que nadie vive como superintendente, tú no trabajas como root en el día a día. Más adelante en este módulo vas a ver exactamente cuándo pedir prestado ese poder con sudo es la herramienta correcta y cuándo es la señal de que algo más anda mal; por ahora quédate con esto: root existe porque alguien tiene que poder hacerlo todo, y tú no eres ese alguien todo el tiempo.

Ejemplo trabajado

Cuatro comandos te dicen, con distinto nivel de detalle, quién eres para el sistema en este momento.

whoami
id
groups
who

Qué esperar (salida típica en una distribución Linux; en macOS los números y nombres de grupo cambian, pero la forma es la misma):

$ whoami
dev

$ id
uid=1000(dev) gid=1000(dev) groups=1000(dev),27(sudo),999(docker)

$ groups
dev sudo docker

$ who
dev      pts/0        2026-07-21 09:14 (203.0.113.20)

Léelo de afuera hacia adentro:

• whoami responde una sola pregunta: ¿qué usuario soy en este momento? Nada más. Es la versión mínima, pensada para usarse dentro de scripts que necesitan una sola línea de texto.
• id es la ficha completa: tu UID (1000), tu grupo primario o GID (1000, que aquí coincide con tu propio nombre — muchas distribuciones crean un grupo privado idéntico al usuario en el momento en que lo dan de alta) y la lista completa de grupos secundarios a los que perteneces. Aquí sudo y docker no son decoración: pertenecer a sudo es literalmente lo que te habilita a usar ese comando, y pertenecer a docker es lo que te deja correr contenedores sin escribir sudo antes de cada uno.
• groups es un atajo: la misma lista de grupos de id, sin los números, para cuando solo te interesan los nombres.
• who responde una pregunta distinta a las otras tres: no "quién soy yo", sino "quién está conectado a esta máquina ahora mismo" — cada sesión activa, con su terminal y, si te conectaste por SSH, la dirección desde la que entraste. En tu laptop vas a ver solo tu propia sesión; en un servidor compartido vas a ver una línea por cada persona conectada en ese momento, que es exactamente el escenario para el que se diseñó el comando.

Las tres clases de todo archivo: propietario, grupo, otros

El mismo modelo de usuario y grupo se repite, archivo por archivo, en tres categorías fijas que Unix aplica sin excepción:

1. Propietario (owner): el usuario específico dueño del archivo — normalmente quien lo creó.
2. Grupo (group): el grupo asociado al archivo. Cualquier usuario que pertenezca a ese grupo hereda el nivel de acceso que el archivo le asigna a la categoría "grupo", sin importar quién sea individualmente.
3. Otros (others): todo el resto — cualquier usuario del sistema que no sea el propietario ni pertenezca al grupo del archivo. Es la categoría del repartidor del edificio: existe, puede necesitar entrar, pero por defecto no tiene ninguna llave.

Ya viste en el módulo anterior que ls -l imprime una columna con una forma como drwxr-xr-x. Esa cadena describe exactamente estas tres clases —tres bloques de caracteres, uno por categoría—, pero decodificar cada letra en detalle y cambiarlas con chmod es el tema completo de la siguiente lección. Lo único que necesitas hoy es reconocer que propietario, grupo y otros no son un detalle de una pantalla: son el modelo completo de control de acceso de Unix, aplicado a cada uno de los archivos de tu disco, siempre en ese orden.

Por qué "Permission denied" es una señal de que el sistema funciona

Cuando el sistema te devuelve Permission denied, es fácil sentirlo como un obstáculo caprichoso. Es lo contrario: es el kernel aplicando, correctamente, las tres clases que acabas de ver. Sin esa verificación, cualquier usuario en un servidor compartido podría leer, modificar o borrar los archivos de cualquier otro usuario con solo escribir la ruta correcta — el aislamiento que permite que diez personas distintas usen la misma máquina sin pisarse dejaría de existir.

Ese aislamiento se apoya en una idea que vas a ver repetida en todo el módulo, hoy en su forma más simple, antes de que exista un solo comando para aplicarla: el criterio de menor privilegio. Dice, en esencia, que cada identidad —un usuario, un proceso, un script— debería tener exactamente el acceso que necesita para hacer su trabajo, ni un permiso más. No es una regla de seguridad paranoica: es matemática de daño. Si un proceso comprometido o un script con un error corre con acceso a todo el disco, el daño potencial es todo el disco. Si ese mismo proceso solo tiene acceso a la carpeta que realmente necesita, el daño posible queda acotado a esa carpeta. root existe precisamente porque alguna identidad necesita el acceso total para tareas de administración — pero por la misma lógica, ningún trabajo cotidiano debería hacerse con esa identidad, de la misma forma en que el superintendente del edificio no le presta la llave maestra a un inquilino solo porque perdió la suya.

Errores comunes

"Es mi computadora, así que debería poder hacer lo que quiera todo el tiempo" (conceptual). Qué pasa: el estudiante interpreta cada Permission denied en su propia laptop como un error del sistema, razonando "esta máquina es mía". Por qué ocurre: confunde la propiedad legal del hardware con el modelo de identidades del sistema operativo — son cosas distintas. El sistema no sabe ni le importa de quién es la laptop; solo sabe qué UID pidió qué acceso sobre qué archivo. Cómo detectarlo: si tu reacción automática ante cualquier error de permisos es "pero si es mi computadora", ese es el síntoma. Cómo corregirlo: recuerda que incluso en tu propia laptop existen múltiples cuentas (la tuya, root, cuentas de servicio) y que el modelo trata tu máquina exactamente igual que trataría un servidor con cien usuarios reales — la protección existe para cuando algo (un script, un proceso comprometido, un error tuyo) intenta hacer más de lo que debería, sin importar de quién sea el hardware.

Confundir el nombre de usuario con el UID. Qué pasa: al copiar archivos desde otra máquina, restaurar un backup viejo, o leer un volumen montado de un contenedor Docker, ls -l muestra un número (por ejemplo 1005) en la columna de propietario en vez de un nombre. El estudiante asume que el archivo está roto o corrupto. Por qué ocurre: el sistema de archivos no guarda el texto "ana" dentro del archivo — guarda únicamente el número de UID. ls traduce ese número a un nombre legible consultando la base de usuarios local; si esa máquina no tiene ningún usuario dado de alta con ese UID —porque el archivo vino de otro sistema, porque el usuario original ya fue borrado, o porque un contenedor usa un mapeo de UID distinto— no hay nombre que mostrar, y aparece el número crudo. Cómo detectarlo: ves un número donde esperarías un nombre en la salida de ls -l. Cómo corregirlo: no es corrupción — es información real. Puedes intentar id 1005 para ver si ese UID corresponde a algún usuario existente en tu máquina; si el comando no encuentra a nadie con ese identificador, confirmas que el propietario original no existe localmente, y sabes que el problema no es el archivo sino el contexto del que vino.

Mirar solo el primer grupo de groups e ignorar el resto. Qué pasa: el estudiante ejecuta groups, ve una lista, y solo le presta atención al primer nombre —normalmente el grupo primario, casi siempre igual a su propio usuario— asumiendo que los demás son ruido decorativo. Por qué ocurre: el primer valor parece "el importante" porque coincide con el nombre de usuario, y los demás pasan desapercibidos. Cómo detectarlo: si te preguntan "¿puedes correr Docker sin sudo?" o "¿tienes permiso para usar sudo?" y necesitas ir a revisar en vez de saber la respuesta de memoria mirando tu propio groups, esa es la señal. Cómo corregirlo: trata cada grupo secundario de la lista como una capacidad real y activa, no como metadata: pertenecer a sudo es lo que te permite usar sudo; pertenecer a docker es lo que te permite usar Docker sin él. La lista completa de groups es, literalmente, la lista de capacidades que tienes activadas ahora mismo.

Ejercicios

1. Ejecuta whoami, id, groups y who en tu propia terminal. Con la salida real frente a ti, contesta: ¿tu grupo primario tiene el mismo nombre que tu usuario? ¿A qué grupos secundarios perteneces, y qué capacidad real te da cada uno?

Ver solución

No hay una única respuesta correcta porque depende de tu máquina — el ejercicio busca que interpretes tu propia salida, no que la compares contra un valor fijo. Si tu sistema sigue la convención de crear un grupo privado por usuario (común en Debian, Ubuntu y derivados), tu grupo primario va a coincidir con tu nombre de usuario. Para cada grupo secundario que aparezca (por ejemplo sudo, docker, wheel, admin), la pregunta correcta no es "¿cómo se llama?" sino "¿qué puedo hacer por pertenecer a él que no podría hacer si no perteneciera?". Esto funciona porque el propósito del ejercicio es que dejes de ver groups como texto decorativo y empieces a leerlo como una lista de capacidades activas.

2. Un compañero de equipo te manda esta salida de id de su propia cuenta y te pregunta si puede correr sudo apt update sin que el sistema lo rechace:

uid=1002(sam) gid=1002(sam) groups=1002(sam),999(docker)

¿Puede? Justifica tu respuesta usando solo esta línea.

Ver solución

No puede — al menos no sin que alguien se lo habilite antes. La lista de groups de sam es sam (su grupo primario) y docker; en ningún lugar aparece sudo ni ningún grupo administrativo equivalente. La capacidad de usar sudo no depende de "ser un usuario válido del sistema" — depende, en la mayoría de las distribuciones Linux, de pertenecer específicamente al grupo sudo (o wheel, según la distribución) y tener una regla que lo autorice. Esto funciona porque sudo no es un permiso universal de todo usuario: es una capacidad que se otorga por membresía de grupo, exactamente como cualquier otra.

3. Al listar una carpeta compartida en un servidor, ves esta línea:

-rw-r--r-- 1 1005 1005 2048 Jul 20 10:03 report.csv

En vez de un nombre de usuario, aparece 1005 dos veces. ¿Qué explica esto, y qué harías para confirmarlo?

Ver solución

1005 es el UID (y el GID) numérico del propietario original del archivo, y ls -l no pudo traducirlo a un nombre legible porque esta máquina no tiene ningún usuario dado de alta con ese identificador — puede ser que el archivo llegó de otro servidor, que el usuario original fue borrado de esta máquina después de crear el archivo, o que viene de un contenedor con un esquema de UID distinto. Para confirmarlo, intentarías resolver ese UID contra la base de usuarios local (por ejemplo con id 1005); si no encuentra ningún usuario correspondiente, confirmas que el propietario simplemente no existe en este sistema — el archivo no está roto, solo referencia una identidad ajena a esta máquina. Esto funciona porque el sistema de archivos nunca guarda nombres, solo números; el nombre es una traducción que depende enteramente de que exista una entrada local para ese número.

4. Explica con tus propias palabras por qué root no debería ser tu usuario de trabajo diario, aunque tengas la contraseña y técnicamente puedas iniciar sesión como root en cualquier momento.

Ver solución

Porque root (UID 0) hace que el kernel se salte por completo las verificaciones de permisos: cualquier proceso que corras como root tiene acceso sin restricción a todo el sistema, sin la protección de las tres clases —propietario, grupo, otros— que existen justamente para acotar el daño posible de un error o de un proceso comprometido. Si trabajas el día a día como root, un simple error de tipeo en un comando, o un script con un bug, tiene el mismo alcance destructivo que tendría un ataque deliberado: todo el disco, sin excepción. Trabajando con tu usuario normal, ese mismo error queda acotado a lo que tu usuario puede tocar. Esto funciona porque es exactamente el criterio de menor privilegio aplicado a ti mismo: usa el nivel de acceso que tu tarea necesita, no el máximo disponible, y pide prestado el máximo solo cuando una tarea puntual realmente lo exige.

Resumen y siguiente paso

Hoy viste que tu laptop, aunque la uses tú solo, sigue el mismo modelo multiusuario con el que Unix se diseñó para mainframes compartidos: cada identidad tiene un usuario (con su UID), pertenece a un grupo primario y puede tener grupos secundarios, y whoami, id, groups y who son las cuatro formas de consultar esa identidad con distinto nivel de detalle. Viste también que todo archivo aplica ese mismo modelo en tres clases fijas —propietario, grupo, otros— y que root (UID 0) es la única identidad que el kernel exime de esas verificaciones, razón exacta por la que no es tu cuenta de trabajo diario. Permission denied no es una molestia del sistema: es el criterio de menor privilegio funcionando delante de tus ojos.

Antes de avanzar deberías poder: ejecutar los cuatro comandos de identidad e interpretar cada campo de su salida sin ayuda; explicar de memoria qué son las tres clases de permisos sin haber visto todavía el símbolo rwx; y explicar, con tus propias palabras, por qué ver un número en vez de un nombre en ls -l no significa que un archivo esté dañado.

Lo que aprendiste hoy —que cada archivo distingue entre propietario, grupo y otros— es exactamente la estructura que vas a leer carácter por carácter en la cadena drwxr-xr-x en la siguiente lección, cuando conectes ese modelo con chmod y aprendas a cambiarlo tú mismo, tanto en notación simbólica como en octal.

Recursos

• id invocation — GNU Coreutils Manual — referencia oficial de todas las opciones de id, incluida la diferencia entre UID real y efectivo.
• who invocation — GNU Coreutils Manual — qué información expone who sobre cada sesión activa en el sistema.
• groups invocation — GNU Coreutils Manual — documentación oficial de groups y su relación con id -Gn.
• id(1) — Linux manual page — man page canónica de id, con el detalle de cómo resuelve nombres y números.
• Superuser — Wikipedia — historia y definición de la cuenta root/administrador en sistemas Unix y por qué el kernel la trata como caso especial.