Problema

Es común encontrarse con entornos donde la gestión de privilegios se ha vuelto demasiado restrictiva, ya sea por una auditoría de seguridad mal interpretada o una limpieza agresiva del archivo sudoers. El síntoma es claro: al intentar ejecutar comandos como reboot, shutdown o poweroff como usuario sin privilegios, el sistema rechaza la solicitud de manera tajante.

El error suele manifestarse con mensajes relacionados con la imposibilidad de hablar con el daemon de inicialización o fallos en la autenticación interactiva (polkit). En esencia, el usuario no tiene la autorización necesaria delegada por systemd-logind o polkit para realizar una acción de ciclo de vida del sistema, y al no tener acceso a sudo, el camino convencional hacia la administración queda bloqueado.

Causa

La causa raíz suele ser una configuración de PolicyKit (polkit) o systemd que requiere autenticación administrativa para acciones privilegiadas, combinada con la ausencia de permisos en el grupo wheel o sudo.

Cuando systemd intenta ejecutar un reboot, verifica primero si el usuario tiene una sesión activa en la consola (vía logind) o si tiene los permisos necesarios definidos en las reglas de polkit. Si el archivo de configuración de sudoers fue purgado, los métodos estándar de elevación desaparecen. Si además las reglas de polkit no permiten explícitamente que usuarios estándar realicen acciones de apagado, el intento de comunicación con el bus de sistema (dbus) fallará. El error “failed to open initctl fifo” es una señal de que el usuario no tiene permisos para interactuar con los procesos de control de init, algo que está intrínsecamente ligado a la falta de privilegios efectivos.

Solución

La solución consiste en delegar la capacidad de realizar acciones específicas de systemd a usuarios o grupos específicos mediante reglas de polkit, sin necesidad de otorgar acceso total a sudo.

Para delegar la capacidad de reinicio, debemos crear una regla personalizada en /etc/polkit-1/rules.d/. El objetivo es interceptar la acción org.freedesktop.login1.reboot y permitirla basándonos en la pertenencia del usuario a un grupo específico, incluso si dicho usuario no está en sudoers.

Si el sistema ya está en un estado donde no puedes editar estos archivos por falta de permisos, la única vía es el acceso físico o de consola a través de un usuario que aún posea acceso raíz o mediante el uso de parámetros de arranque del kernel (init=/bin/bash) para recuperar el acceso.

Cuándo aplicar esta solución

  • Entornos de kiosco o terminales compartidos: Donde se requiere que usuarios sin privilegios puedan reiniciar el equipo.
  • Delegación de tareas: Cuando quieres permitir que operadores realicen mantenimientos básicos sin darles control total sobre la configuración del servidor.
  • Recuperación tras bloqueo: Como medida correctiva cuando una política de seguridad demasiado estricta ha dejado al sistema “huérfano” de administración.

No apliques esto si el servidor requiere controles de auditoría estrictos que impidan reinicios no registrados. En entornos de alta seguridad, la capacidad de reiniciar debe ser siempre auditable.

Código

Crea un archivo nuevo, por ejemplo, `10-allow-reboot.rules`, en la ruta indicada. El motor de reglas de `polkit` evaluará este archivo y permitirá la acción solicitada.

```bash
cat <<EOF > /etc/polkit-1/rules.d/10-allow-reboot.rules
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.login1.reboot" ||
        action.id == "org.freedesktop.login1.reboot-multiple-sessions" ||
        action.id == "org.freedesktop.login1.power-off" ||
        action.id == "org.freedesktop.login1.power-off-multiple-sessions") {
        if (subject.isInGroup("nombre-de-tu-grupo")) {
            return polkit.Result.YES;
        }
    }
});
EOF

Asegúrate de reemplazar nombre-de-tu-grupo con el grupo al que pertenecen los usuarios que necesitan esta capacidad. No es necesario reiniciar ningún servicio; polkit recarga estas reglas dinámicamente.


## Verificación
Para verificar que la regla está funcionando, puedes probar el comando como usuario sin privilegios. Si la regla es efectiva, el sistema debería iniciar el proceso de apagado inmediatamente sin solicitar contraseña ni lanzar errores de `polkit`.

También puedes inspeccionar las acciones permitidas para tu usuario usando:

```bash
pkcheck --action-id org.freedesktop.login1.reboot --process $$

Si el comando no devuelve ningún error y el código de salida es 0, la autorización es correcta.

Notas adicionales

  • Rutas de archivos: En versiones más recientes de RHEL o distribuciones modernas, polkit puede estar muy ligado a systemd. Si el comando sigue fallando, revisa que no haya archivos en /etc/polkit-1/rules.d/ que estén denegando explícitamente la acción de forma prioritaria (los archivos se leen en orden alfabético).
  • Sesiones inactivas: polkit a veces distingue entre sesiones activas (en consola física) y remotas (SSH). Si estás probando vía SSH y no funciona, verifica si la acción reboot-multiple-sessions es necesaria para cubrir el caso de uso remoto.
  • Persistencia: Este método es persistente entre reinicios. Es mucho más seguro y limpio que intentar alterar permisos de binarios específicos como /usr/sbin/reboot.