Actuar como administrador: su y sudo

1. El privilegio justo

En el tema 16 conocimos a root, el usuario con UID 0, al que los permisos no se le aplican. Y vimos el principio que organiza todo el sistema:

El principio de mínimo privilegio establece que cada usuario y cada programa deben tener, en cada momento, solo los permisos necesarios para la tarea que están realizando.

Aplicado a las personas, lleva a separar dos clases de trabajo:

La última fila es la idea del tema. No hace falta ser administrador todo el día para administrar a veces. Hace falta un mecanismo para tomar el privilegio cuando se lo necesita y soltarlo enseguida.

2. Por qué no se trabaja como root

Sería más cómodo iniciar sesión como root y olvidarse de los Permission denied. Todo lo que aprendimos en este bloque explica por qué no se hace:

La shell avisa con qué identidad se está trabajando, mediante el último carácter del indicador. Es una convención que vale en todos los sistemas, y que conviene tener incorporada:

Un # al final del indicador es una señal de alerta: a partir de ahí, cada línea se lee dos veces.

3. Dos caminos: su y sudo

Hay dos herramientas para obtener privilegios desde una sesión común. Responden a dos modelos distintos de administración:

El modelo de su es el más antiguo: existe una contraseña de root, y quienes administran la conocen. El de sudo prescinde de ese secreto compartido. Cada administrador usa su propia contraseña, y el sistema decide, por una lista, quién puede hacer qué.

Ubuntu adopta el segundo modelo de manera estricta: la cuenta root existe pero no tiene contraseña, de modo que nadie puede iniciar sesión con ella ni llegar a ella con su. Otras distribuciones, como Debian o Fedora, permiten elegir durante la instalación. Hoy sudo es lo habitual en casi todas.

4. su: convertirse en otro usuario

su, de substitute user, inicia una shell con la identidad de otra cuenta. Sin argumentos, esa cuenta es root. Hay que conocerlo aunque en Ubuntu se use poco, porque aparece en cualquier otro sistema y en mucha documentación:

La diferencia entre las dos primeras filas es un guion, y es importante. Sin él, se obtiene la identidad de root dentro del entorno de otro usuario: una mezcla que produce comportamientos extraños, como comandos de administración que no se encuentran porque el PATH no es el de root. La forma recomendable es siempre su -.

En Ubuntu, el intento termina así:

$ su -
Password:
su: Authentication failure

No hay contraseña que acertar, porque la cuenta no tiene ninguna. Como root no necesita contraseña para cambiar de usuario, su conserva un uso práctico cuando ya se es administrador: sudo su - luis abre una sesión como otro usuario sin conocer su clave, para probar algo desde su punto de vista.

5. sudo: un comando con privilegios

sudo se antepone a un comando, y lo ejecuta con la identidad de root. El nombre se suele explicar como superuser do, «que lo haga el superusuario».

$ whoami
ana
$ sudo whoami
[sudo] password for ana:
root
$ whoami
ana

Las tres líneas cuentan todo. Antes y después, la shell es de ana. En el medio, un solo proceso corrió como root, y al terminar el privilegio desapareció con él.

Con esa identidad, el comando pasa por donde los permisos cerraban el paso. El archivo de contraseñas, que en el tema 16 no pudimos leer:

$ head -n 1 /etc/shadow
head: cannot open '/etc/shadow' for reading: Permission denied
$ sudo head -n 1 /etc/shadow
root:!:19835:0:99999:7:::

La línea confirma lo dicho en la sección 3. El segundo campo, donde debería estar el hash de la contraseña de root, contiene un signo de exclamación: la marca de una cuenta sin contraseña utilizable.

Esto mismo ocurrió cada vez que escribimos sudo apt install. Instalar un programa es escribir en /usr y en /etc, directorios de root, y hace falta su identidad.

6. La contraseña y su memoria

La contraseña que pide sudo es la del usuario que lo ejecuta, no la de root. No sirve para demostrar que se conoce un secreto de administración, sino para confirmar que quien está al teclado es realmente el dueño de la sesión, y no alguien que encontró la terminal abierta.

Mientras se escribe no aparece nada en la pantalla, ni asteriscos, como advertimos en el tema 2. Es deliberado: ni siquiera se revela cuántos caracteres tiene.

Para no pedirla en cada línea, sudo recuerda durante un tiempo que ya la verificó:

Esa memoria es cómoda y es también una ventana: durante esos minutos, cualquier cosa que se ejecute con sudo en esa terminal lo hará sin preguntar. Al dejar el equipo sin bloquear después de una tarea de administración, sudo -k la cierra.

En algunas distribuciones, la primera vez que un usuario ejecuta sudo recibe un aviso que se ha vuelto célebre, y que resume la actitud que la herramienta espera:

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Respetar la privacidad de los demás, pensar antes de escribir, y recordar que un gran poder conlleva una gran responsabilidad.

7. Quién puede usar sudo

No cualquiera. sudo consulta una configuración que dice qué usuarios pueden ejecutar qué comandos. En Ubuntu la regla principal es simple y ya la conocemos: pueden usarlo los miembros del grupo sudo. El usuario creado durante la instalación pertenece a él, como mostró id.

Un usuario que no está autorizado recibe una negativa, y el intento se anota:

luis@equipo:~$ sudo apt update
[sudo] password for luis:
luis is not in the sudoers file.

El comando sudo -l, de list, muestra qué se le permite al usuario actual:

$ sudo -l
Matching Defaults entries for ana on equipo:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User ana may run the following commands on equipo:
    (ALL : ALL) ALL

La línea resaltada es el permiso: cualquier comando, como cualquier usuario y grupo. Es lo que tiene un administrador. En un servidor bien configurado, la respuesta para otros usuarios puede ser una lista corta de comandos concretos, que es justamente lo que su no sabe hacer.

Las primeras líneas son ajustes de seguridad. Uno merece mención: secure_path hace que sudo use su propia lista de directorios para buscar comandos, y no el PATH del usuario. Evita que alguien coloque un programa falso llamado ls en un directorio propio y logre que se ejecute como root.

8. Las opciones de sudo

La segunda fila muestra que sudo no es solo para llegar a root. Sirve para ejecutar algo con la identidad limitada de un servicio, y comprobar qué ve y qué puede hacer:

$ sudo -u www-data whoami
www-data
$ sudo -u www-data cat /home/ana/practica/notas.txt
cat: /home/ana/practica/notas.txt: Permission denied

El segundo comando verifica en la práctica lo que dedujimos con namei en el tema 17: otro usuario no llega al archivo, aunque tenga lectura para «otros», porque no puede atravesar /home/ana.

sudoedit es la forma correcta de editar configuración, mejor que sudo nano. Copia el archivo a un lugar temporal, abre el editor como tu usuario, y al guardar reemplaza el original con privilegios. El editor, con todos sus complementos, nunca corre como root. Usa el editor indicado en la variable EDITOR, de la que hablamos en el tema 13.

9. Una shell de root

Cuando una tarea de administración tiene muchos pasos, anteponer sudo a cada línea cansa, y hay operaciones que no se pueden hacer de otro modo, como veremos en la sección siguiente. Para esos casos se abre una shell completa con la identidad de root:

ana@equipo:~/practica$ sudo -i
root@equipo:~# pwd
/root
root@equipo:~# whoami
root
root@equipo:~# exit
logout
ana@equipo:~/practica$ 

El indicador cambió en sus tres partes: el usuario, el directorio —ahora ~ es /root— y, sobre todo, el carácter final, que pasó de $ a #. Hay varias maneras de llegar a una shell así, con diferencias en el entorno:

10. Las trampas de sudo

sudo da privilegios al comando que recibe, y solo a él. Todo lo que la shell hace antes de ejecutarlo —y vimos en el tema 9 que es mucho— lo sigue haciendo como tu usuario. De ahí salen cuatro fallos que desconciertan, porque el comando lleva sudo y aun así es rechazado.

La redirección. Escribir en un archivo del sistema con > no funciona:

$ sudo echo "prueba" > /etc/prueba.conf
bash: /etc/prueba.conf: Permission denied

El mensaje empieza con bash: quien se queja es la shell. El archivo de destino lo abre ella, con la identidad de ana, antes de lanzar nada. Lo único que corre como root es echo, que no necesitaba privilegios. La solución habitual es dejar la escritura a un programa que sí corra con sudo. Ese programa es tee, que escribe en un archivo lo que recibe por una tubería:

echo "prueba" | sudo tee /etc/prueba.conf            # reemplaza el contenido
echo "prueba" | sudo tee -a /etc/prueba.conf         # agrega al final

Los comodines. Los expande la shell, antes de sudo, y no puede listar un directorio que le está vedado:

$ sudo ls /root/*
ls: cannot access '/root/*': No such file or directory

Como ana no puede leer /root, el patrón no coincide con nada y pasa literal, según la tercera regla de los comodines. ls, ya como root, busca un archivo llamado asterisco.

Los comandos internos. sudo ejecuta programas, y un comando interno de la shell no lo es:

$ sudo cd /root
sudo: cd: command not found

Aunque existiera, no serviría: cambiaría el directorio de un proceso que termina enseguida, y no el de tu shell. Es el argumento del tema 6 sobre por qué cd es interno.

Los alias. Son de tu shell, y sudo no los conoce: sudo ll responde command not found.

La segunda solución es general: sudo sh -c '…' lanza como root una shell nueva, que interpreta todo lo que está entre comillas —comodines, redirecciones, tuberías— con privilegios. Las comillas simples son indispensables, para que tu shell no toque nada.

11. Todo queda anotado

Cada uso de sudo se registra: quién, cuándo, desde qué terminal, en qué directorio y con qué comando exacto. En Ubuntu, en /var/log/auth.log, que los miembros del grupo adm pueden leer:

$ grep COMMAND /var/log/auth.log | tail -n 1
2026-10-12T17:10:42.318274-03:00 equipo sudo:      ana : TTY=pts/0 ; PWD=/home/ana/practica ; USER=root ; COMMAND=/usr/bin/head -n 1 /etc/shadow

Este registro es una de las razones de fondo para preferir sudo a su, y a una shell de root prolongada:

No es una herramienta para vigilar a nadie, sino para reconstruir. Cuando algo deja de funcionar, la pregunta «¿qué se cambió ayer?» tiene respuesta. Y cuando hay varios administradores, la responsabilidad de cada acción es individual, cosa imposible con una contraseña compartida.

12. El archivo sudoers

La configuración de sudo está en /etc/sudoers, y en los archivos del directorio /etc/sudoers.d. En el tema 17 vimos que sus permisos son r--r-----, sin escritura ni para su dueño, como advertencia de que no se edita a mano. Las líneas que importan son pocas:

$ sudo cat /etc/sudoers
Defaults        env_reset
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

root    ALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

@includedir /etc/sudoers.d

%sudo ALL=(ALL:ALL) ALL
│     │    │        │
│     │    │        └─ qué comandos: todos
│     │    └─ como qué usuario y grupo: cualquiera
│     └─ desde qué equipo: cualquiera
└─ quién: los miembros del grupo sudo (el % indica un grupo)

Esa línea es la que hace administradores a los miembros del grupo sudo. La potencia del formato está en que cada parte se puede restringir. Una regla como la siguiente permite a un usuario reiniciar un servicio, y nada más:

luis ALL=(root) /usr/bin/systemctl restart nginx

Es el principio de mínimo privilegio llevado a la práctica: quien necesita una sola operación de administración recibe exactamente esa.

Dos apuntes más. Lo aconsejable es no tocar el archivo principal y agregar las reglas propias en /etc/sudoers.d, la convención de directorios .d que vimos en el tema 8. Y existe una etiqueta, NOPASSWD:, que exime de la contraseña. Es razonable para un comando preciso que debe ejecutar un script automático; aplicada a todos los comandos de un usuario, convierte cualquier programa que ese usuario ejecute en root sin pregunta alguna.

13. Usar sudo con criterio

Para cerrar, las costumbres que distinguen a quien usa sudo como una herramienta de quien lo usa como un conjuro:

El cuarto punto tiene una forma particularmente riesgosa, que encontrarás en muchas instrucciones de instalación: descargar un script y pasarlo directamente a una shell con privilegios, en una sola línea. Es ejecutar como root un programa que nadie leyó. Lo prudente es descargarlo a un archivo, leerlo con less, y ejecutarlo después.

La referencia del tema:

Con la capacidad de actuar como administrador, podemos hacer lo que hasta ahora solo consultamos. En el tema 20 creamos usuarios y grupos, les asignamos contraseñas y membresías, y los damos de baja.

14. Resumen

• El principio de mínimo privilegio pide usar la identidad de administrador solo para las tareas que la requieren, y solo mientras duran.
• Trabajar como root elimina la protección de los permisos, da el control del equipo a todo programa que se ejecute y no deja constancia de quién hizo qué.
• Un indicador terminado en # señala una shell de root; en $, la de un usuario común.
• su abre una shell como otro usuario y pide la contraseña de ese usuario. su - carga además su entorno.
• sudo ejecuta un solo comando como root y pide la contraseña del propio usuario.
• En Ubuntu la cuenta root no tiene contraseña: se administra exclusivamente con sudo.
• sudo recuerda la contraseña verificada durante 15 minutos; sudo -k la olvida.
• Pueden usar sudo los usuarios autorizados en su configuración; en Ubuntu, los miembros del grupo sudo. sudo -l muestra los permisos.
• sudo -u ejecuta como otro usuario; sudoedit edita archivos del sistema; sudo -i abre una shell de root.
• sudo solo da privilegios al comando: las redirecciones, los comodines y los alias los resuelve antes la shell del usuario. Para escribir en un archivo del sistema se usa | sudo tee.
• Cada comando ejecutado con sudo queda registrado con el usuario que lo lanzó.
• La configuración está en /etc/sudoers y /etc/sudoers.d, y se edita solo con visudo, que valida la sintaxis.

15. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Ejecuta id y sudo id, y compara las dos salidas.
2. Ejecuta sudo -l e identifica la línea que te autoriza. ¿Qué directorios figuran en secure_path?
3. Ejecuta sudo true, y luego sudo -k seguido de otro sudo true. ¿En cuál se pidió la contraseña?
4. Abre una shell de root con sudo -i. Observa el indicador, ejecuta pwd, whoami y echo $HOME, y sal de inmediato. Repite con sudo -s y compara.
5. Ejecuta sudo -u nobody whoami y sudo -u nobody ls ~. Explica el segundo resultado con namei -l ~.
6. Reproduce el error de la sección 10 con sudo echo hola > /root/hola.txt. Luego hazlo bien con tee, comprueba con sudo cat, y borra el archivo con sudo rm /root/hola.txt.
7. Compara sudo ls /root/* con sudo sh -c 'ls /root/*'.
8. Busca en /var/log/auth.log los últimos cinco usos de sudo: grep COMMAND /var/log/auth.log | tail -n 5. Reconoce los comandos de los ejercicios anteriores.
9. Lee la configuración con sudo cat /etc/sudoers y lista /etc/sudoers.d. Comprueba la sintaxis, sin modificar nada, con sudo visudo -c.
10. Con sudo touch ~/practica/de-root.txt, crea un archivo como root en tu directorio. Mira su dueño, intenta agregarle una línea, y resuélvelo con chown. Bórralo al terminar.