Permitir que un grupo que no sea sudo controle el trabajo de Upstart


11

Estoy tratando de configurar un trabajo Upstart para que se ejecute en el inicio del sistema, y ​​eso también puede ser iniciado / detenido por miembros de un grupo que no sea sudo. Con una versión anterior, utilicé los update-rc.dscripts almacenados /etc/init.d/para que esto funcionara agregando %Group ALL = NOPASSWD: /etc/init.d/scriptnamea mi archivo sudoers, pero parece que no puedo obtener un equivalente que funcione para Upstart.

Intenté agregar %Group ALL = NOPASSWD: /sbin/initctl start jobnameal archivo sudoers, pero intentar ejecutar el comando start jobnameproduce este error:

start: Rejected send message, 1 matched rules; type="method_call", sender=":1.21" (uid=1000 pid=5148 comm="start jobname " interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")

Por lo que puedo decir, esa es una queja sobre cómo mi cuenta de usuario no tiene el poder de enviar mensajes de 'Inicio' en el archivo de configuración de D-Bus para Upstart. No he podido encontrar ninguna información sobre cómo editar ese archivo para dar permiso a un grupo para acceder a un servicio específico. ¿Existe esa opción? ¿Hay alguna manera de editar el archivo Sudoers para que pueda ejecutar el trabajo sin editar el archivo de configuración? ¿Es mejor que me quede con la versión anterior?

Respuestas:


7

Puede comenzar descubriendo dónde se mantiene la configuración D-Bus específica para Upstart. ¿Ves ese destination="com.ubuntu.Upstart"fragmento del mensaje de error? Ahora intente grep en la carpeta con los archivos de configuración de D-Bus:

vhost07:~ $ grep -r "com.ubuntu.Upstart" /etc/dbus-1
/etc/dbus-1/system.d/Upstart.conf:    <allow own="com.ubuntu.Upstart" />
[...skipped...]

Ese Upstart.confarchivo tiene algunos ejemplos de políticas. Supongo que podría intentar averiguar el formato de una política a partir de ellos. Luego intente permitir a su usuario específico solo las acciones que necesita. Por ejemplo, como en:

<policy user="pope_benedict">
  <allow send_destination="com.ubuntu.Upstart"
         send_interface="com.ubuntu.Upstart0_6.Job"
         send_member="Start"/>
</policy>

Esto debería permitir al pope_benedictusuario comenzar ese trabajo.

Tenga en cuenta que los valores para los atributos de política 'permitir' se enumeran en su mensaje de error original.


1
¡Ah, y no olvides reiniciar D-Bus después de esto! :)
Iuliu Pascaru

Esto me pareció un poco desconcertante, pero me ayudó: blog.arkency.com/2014/07/…
Mike Campbell

7

Personalmente estoy usando la siguiente línea en el archivo /etc/sudoers.d/jobname_myuser:

myuser ALL = (root) NOPASSWD: /sbin/start jobname, /sbin/stop jobname, /sbin/restart jobname, /sbin/status jobname

como se describe aquí: /server//a/390723/68608


2

Dicha opción no existe en sudo.

La diferencia entre los scripts de Sysv y los archivos de configuración de Upstart es solo eso: los scripts de Sysv son scripts, ejecutables por derecho propio y puede decirle a sudo que permita que algún grupo los ejecute. Por otro lado, los archivos de configuración de Upstart son simplemente archivos de configuración, no ejecutables, por lo que la ejecución de start(enlace simbólico a initctl) es lo que permite sudo. Su problema aquí es que permitir que las personas lo ejecuten initctlles permite initctltodo.

La solución es simple si su preocupación es simplemente un solo trabajo. Haz un guión, di /usr/bin/jobname.shcon

#!/bin/sh
initctl $1 jobname

luego chmod 755 /usr/bin/jobname.shy finalmente agregue ese ejecutable a su archivo sudoers:

%Group ALL = NOPASSWD: /usr/bin/jobname.sh

De esta manera, todos pueden llamar jobname.sh starto jobname.sh stopcontrolar este trabajo específico. Es posible que desee añadir un poco de comprobación para permitir solamente starty stopparámetros, etc.


En otras palabras, mi problema no es que el sistema niegue a los miembros del grupo la capacidad de ejecutarse initctl, sino que Upstart rechaza cualquier señal enviada por usuarios / grupos que no hayan recibido explícitamente una entrada de política Permitir en Upstart.conf. ¿Y no hay forma de proporcionar más granularidad que una configuración de todos los trabajos o ninguno en el archivo de configuración?
Angle O'Saxon el

Initctl en su caso está funcionando bien incluso sin cambios de sudoers, Upstart simplemente rechaza los mensajes si no lo permite específicamente para usuarios no root. Ver las otras dos respuestas. Puede definir la política de dbus por trabajo (consulte la com.ubuntu.Upstart0_6.<JOB>parte) en Upstart.conf. Dependiendo de sus necesidades, puede ser más sencillo hacer este tipo de script para él en lugar de escribir políticas dbus y reiniciar dbus, etc. La política Dbus es obviamente lo "correcto", pero dependiendo de un caso, un script simple puede largo camino con menos problemas.
Tuminoide

Edición de la política de Enlace con el Bus de usar com.ubuntu.Upstart0_6.jobnamecomo el send_interfaceproducido el mismo mensaje de error como antes. Si tengo razón al adivinar que la salida de error contiene la información de la señal, parece que la interfaz o el destino no reflejan el servicio Upstart al que se refiere la señal. Creo que la información del servicio son solo argumentos en el mensaje de llamada del método D-Bus, y no estoy seguro de poder editar la política de D-Bus para Upstart para tomar decisiones basadas en los valores de los argumentos.
Angle O'Saxon

Un script del tipo que sugieres funciona bastante bien para mí, con una advertencia: he estado necesitando ejecutarlo como sudo jobname.sh start, para que Upstart vea que la solicitud proviene del rootusuario. Estoy haciendo un esfuerzo para intentar hacerlo esta es la forma "correcta" (por lo tanto, alejarse de los scripts Sys-V en primer lugar), por lo que me gustaría que esto funcione a través de una política de D-Bus o alguna otra opción de configuración de Upstart, pero si no puedo que funcione, aceptaré esta respuesta.
Angle O'Saxon

1
También lo citaría "$1". Con su [ "$1" = "start" -o "$1" = "stop" ]prueba, creo que es seguro, pero la $1expansión sin comillas en una secuencia de comandos ejecutada como root es un hábito poco saludable (a menos que la división de palabras se desee deliberadamente) ...
Beni Cherniavsky-Paskin

0

Como se señaló anteriormente, dbus daemon tiene un archivo de configuración que lo especializa para una aplicación en particular.

ls /etc/dbus-1/system.d/
avahi-dbus.conf
bluetooth.conf
...
Upstart.conf
wpa_supplicant.con

El archivo de configuración también establece límites de recursos, parámetros de seguridad, etc.

Para más detalles, consulte dbus-daemon-1 (1) - página de manual de Linux

Para permitir que un grupo inicie / detenga trabajos de Upstart, agregue la siguiente política a /etc/dbus-1/system.d/Upstart.conf

  <policy group="YourGroupName">
    <allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Start" />
    <allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Stop" />
  </policy>

Debe considerar las implicaciones de seguridad de dicha política antes de cambiar la política predeterminada. Los miembros de YourGroupName podrán iniciar / detener todos los trabajos de Upstart.


Pero, ¿hay alguna forma de limitar los trabajos que pueden controlar? ¿O eso no es posible porque D-Bus no presta atención al contenido del mensaje?
Angle O'Saxon el

Intenté agregar esa política a Upstart.conf (reemplazando el nombre del grupo con mi nombre de grupo real), reinicié D-Bus y obtuve start: You do not have permission to modify job: jobnamecuando intenté iniciar el servicio.
Angle O'Saxon

OKAY. Eso significa que la política se aplica con éxito. Parece que yourjob.conf está en / etc / init. Los trabajos de los usuarios deben estar en ~ / .init. ¿Es plausible en su caso de uso colocar yourjob.conf en ~ / .init?
Goran Miskovic

Con respecto a su primera pregunta: la política define a qué interfaces y miembros se puede acceder. Define qué contenido / argumentos se pueden enviar / pasar. La política restrictiva actual se ha suavizado río abajo. See no puede iniciarse para ejecutar el trabajo del usuario
Goran Miskovic
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.