Por qué Linux es multiusuario desde su primer día

Publicado el 2026-09-12 por frfrand

De dónde salen los permisos, los uid y la costumbre de que cada servicio tenga su propio usuario, y por qué ese diseño de hace cincuenta años sigue siendo la mejor defensa gratuita que tenés.

Cuando alguien empieza con Linux, los permisos se sienten como burocracia. ¿Por qué tengo que poner sudo para todo? ¿Por qué hay quince usuarios que yo no creé?

La respuesta está en el origen. Unix, del que Linux es heredero directo, nació en 1969 en un mundo donde una computadora costaba lo que hoy cuesta un edificio y la usaban decenas de personas a la vez. No era una máquina personal: era un recurso compartido.

Eso obligó al sistema a responder una pregunta en cada operación: ¿quién está pidiendo esto?

El uid es lo que realmente importa

El sistema no trabaja con nombres, trabaja con números. Cada usuario tiene un identificador, el uid, y el nombre es apenas una etiqueta para que los humanos lo leamos.

$ id uid=1000(deploy) gid=1000(deploy) groups=1000(deploy),27(sudo)

Hay una convención bastante universal:

• uid 0 es root. No es "el administrador" por configuración: es root porque su uid es 0, y el kernel saltea las comprobaciones de permisos para el uid 0. Si le cambiás el nombre, sigue pudiendo todo.
• uid 1 a 999 son usuarios de sistema: servicios, demonios. No tienen contraseña ni shell de login.
• uid 1000 en adelante son las personas.

Por eso whoami puede mentirte y id no: el primero muestra el nombre, el segundo el número.

Cada servicio con su usuario

Esta es la costumbre que más seguridad regala y que más gente rompe sin darse cuenta.

En un servidor bien armado, cada servicio corre como un usuario distinto:

$ ps -eo user,comm | sort -u | head postgres postgres redis redis-server root systemd www-data nginx

La lógica es de contención de daños. Supongamos que aparece una vulnerabilidad en nginx y alguien logra ejecutar código a través de ella. ¿Qué consigue? Los permisos de www-data, que típicamente son leer los archivos del sitio, y poco más.

No puede leer tu .env, porque ese archivo es de deploy con permisos 600. No puede reiniciar servicios, porque eso requiere root. No puede consultar la base de datos, porque las credenciales están en un archivo que no puede abrir.

El ataque ocurrió, pero se quedó adentro de una caja.

Los grupos son el otro eje

Un usuario pertenece a un grupo primario y a los que le agregues. Los grupos resuelven el caso "varias personas necesitan lo mismo".

$ usermod -aG docker deploy # deploy ahora puede usar Docker $ usermod -aG sudo deploy # deploy ahora puede usar sudo

Ojo con la "a" de ese comando: sin ella, usermod -G reemplaza todos los grupos secundarios en vez de agregar. Es una de las formas más rápidas de sacarte a vos mismo del grupo sudo y quedarte sin poder administrar el servidor.

Y un detalle que sorprende: agregar a alguien al grupo docker es, en la práctica, darle root. Quien puede lanzar contenedores puede montar el disco del host adentro de uno. No es un agujero: es cómo funciona Docker. Vale saberlo antes de repartir ese grupo.

Los permisos de un archivo, leídos de una vez

$ ls -l .env -rw------- 1 deploy deploy 412 Nov 1 10:22 .env

Se lee por bloques de tres: el primero es el dueño, el segundo el grupo, el tercero todos los demás. rw- para el dueño, nada para el resto. Eso es 600.

Los números salen de sumar: lectura 4, escritura 2, ejecución 1. Entonces 755 es "el dueño puede todo, el resto puede leer y ejecutar", que es lo normal para una carpeta o un programa. Y 600 es "solamente el dueño, y ni siquiera puede ejecutarlo", que es lo correcto para un archivo de secretos.

Una trampa clásica: en las carpetas, el permiso de ejecución significa "poder entrar". Una carpeta 644 es ilegible aunque sus archivos estén bien.

Por qué esto no es historia antigua

Podría parecer que en un servidor donde trabajás solo todo esto sobra. Es al revés: es justamente ahí donde más importa, porque no hay nadie más mirando.

El modelo multiusuario de Linux es la única defensa que ya está instalada, no cuesta nada y funciona incluso contra ataques que todavía no existen. Aprovecharla es, casi siempre, no pelearse con ella.

En ArduMaker cada VPS se crea con esta estructura ya armada: tu usuario con sudo, los servicios con el suyo, y root reservado para lo que de verdad lo necesita. Los usuarios adicionales se crean desde el panel, con su clave SSH propia.