Si activas el bit setuid en un script de shell propiedad de root, ¿se ejecuta como root?

Una creencia común: chmod u+s script.sh sobre un script de root daría una utilidad rápida que corre como root. En Linux no es así, y eso condiciona cómo se audita la escalada de privilegios.

Qué hace el kernel

La página de manual execve(2) afirma que Linux «(como la mayoría de los Unix modernos) ignora los bits set-user-ID y set-group-ID en los scripts». El kernel lanza el intérprete de la línea #! y el UID efectivo sigue siendo el del invocador. Parte de la razón histórica son las condiciones de carrera entre la comprobación del archivo por el kernel y su reapertura por el intérprete.

Dónde sí se aplica

El bit set-user-ID se respeta al ejecutar un binario nativo. La misma página enumera casos en que se omite, como cuando el sistema de archivos está montado nosuid. El comportamiento en esos montajes varía según la versión del kernel: unos rechazan la ejecución con EPERM, otros ejecutan el archivo sin cambio de privilegios.

Conclusiones de seguridad

Al auditar un host Linux, enumerar binarios SUID es productivo; los scripts SUID no. Si hace falta un ayudante privilegiado, se usa un pequeño wrapper compilado, una regla sudo restringida o capabilities de archivo, cada uno con sus riesgos.

Por qué los distractores tientan

«Se ejecuta como root» es la respuesta intuitiva. «Solo si es escribible por todos» y «solo bash» inventan reglas inexistentes.

Lo que buscan los entrevistadores

«Linux ignora el SUID en scripts; funciona en binarios compilados; nosuid también lo desactiva», con la implicación para la auditoría.