Por qué no usamos root para todo (y qué hacemos en su lugar)

Publicado el 2026-09-12 por frfrand

Trabajar como root no ahorra tiempo: quita las advertencias, rompe los dueños de los archivos y borra el rastro de quién hizo qué. Qué hace sudo realmente y cómo configurarlo bien.

"Entro como root y listo, es más rápido." Lo escuché muchas veces y durante un tiempo lo hice.

El problema es que root no es un modo experto: es un modo sin frenos. El kernel no verifica permisos para el uid 0, así que ninguna de las protecciones que Linux trae encendidas te aplica.

Lo que sigue no es una regla moral, son cuatro consecuencias bastante concretas.

1. No hay red de contención

# rm -rf /var/www/ midirectorio

Ese espacio de más borra /var/www/ entero y después se queja de que midirectorio no existe. Como root, se ejecuta al instante y sin preguntar.

Como usuario normal, ese mismo comando falla con "Permiso denegado" y no pasa nada. El error sigue siendo tuyo, pero el sistema lo atajó.

Muchas de las catástrofes clásicas de administración son exactamente esto: un comando correcto con un argumento equivocado, ejecutado por alguien que podía todo.

2. Rompe los dueños de los archivos

Esta consecuencia es menos dramática y mucho más frecuente.

Si clonás el repositorio como root, todos esos archivos quedan siendo de root. Después tu aplicación, que corre como www-data o como deploy, no puede escribir en la carpeta de caché, o no puede crear el archivo de log, o no puede subir un archivo.

El síntoma aparece días más tarde y no se parece en nada a la causa: un error 500 opaco, una función que "no anda en el servidor pero sí en local". La pista es siempre la misma:

$ ls -l drwxr-xr-x 2 root root 4096 Nov 1 10:15 storage

Ese "root root" donde debería decir "deploy deploy" es el origen del problema.

3. Se pierde el rastro

Si tres personas comparten la contraseña de root, el sistema registra que "root hizo algo". No sirve para nada.

Cuando cada persona entra con su usuario y usa sudo, cada comando privilegiado queda en /var/log/auth.log:

Nov 1 10:22:11 srv sudo: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/bin/systemctl restart nginx

Esto no es para repartir culpas. Es para poder contestar "¿qué cambió acá?" seis semanas después sin depender de la memoria de nadie. En la mayoría de los equipos, esa pregunta se hace mucho más seguido que cualquier auditoría.

4. Y la parte que casi nadie hace: sudo se configura

sudo no es todo o nada. Se puede otorgar permiso para comandos específicos, que es como debería usarse en la mayoría de los casos:

# /etc/sudoers.d/deploy deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart miapp, /bin/systemctl status miapp

Con eso, el usuario deploy puede reiniciar su aplicación sin contraseña y sin poder hacer nada más. Perfecto para un script de despliegue.

Dos advertencias importantes:

• Editá siempre con visudo. Valida la sintaxis antes de guardar. Un error en ese archivo puede dejar a todo el mundo sin sudo, y arreglarlo requiere acceso de consola.
• Cuidado con dar permiso sobre comandos que permiten ejecutar otra cosa. "sudo vim" es, en la práctica, sudo para todo: desde vim se puede abrir una shell.

Lo mínimo que conviene dejar hecho

En /etc/ssh/sshd_config:

PermitRootLogin no PasswordAuthentication no

Lo primero impide entrar como root por SSH directamente. Lo segundo obliga a usar clave. Con esas dos líneas, la enorme mayoría de los intentos automáticos que va a recibir tu servidor dejan de tener sentido.

Antes de recargar: sshd -t para validar, y dejá una segunda sesión abierta por las dudas.

La costumbre que vale la pena

Cuando estés por escribir sudo delante de algo, preguntate: ¿esto necesita root, o el servicio al que pertenece debería estar corriendo con otro usuario?

Muchas veces la respuesta correcta no es dar más permisos, sino arreglar de quién es el archivo.

En ArduMaker los VPS se entregan con el login de root por SSH deshabilitado y tu usuario ya creado con sudo. Y cada comando que se lanza desde el panel queda registrado con quién lo ejecutó, que es la versión automática del auth.log del que hablábamos arriba.