linux - mp3tag - puddletag

La mejor práctica para ejecutar el servicio de Linux como un usuario diferente

Question

Servicios predeterminados para comenzar como root en el momento del arranque en mi caja RHEL. Si recuerdo correctamente, lo mismo es cierto para otras distribuciones de Linux que usan las secuencias de comandos de inicio en /etc/init.d .

¿Cuál cree que es la mejor manera de que los procesos se ejecuten como un usuario (estático) de mi elección?

El único método al que había llegado era usar algo como:

 su my_user -c ''daemon my_cmd &>/dev/null &''

Pero esto parece un poco desordenado ...

¿Hay algo de magia oculto que proporciona un mecanismo fácil para iniciar servicios automáticamente como otros usuarios no root?

EDIT: debería haber dicho que los procesos que estoy comenzando en esta instancia son scripts de Python o programas de Java. Prefiero no escribir un contenedor nativo a su alrededor, así que desafortunadamente no puedo llamar a setuid() como Black sugiere.

Answer 1

Algunas cosas para tener en cuenta:

• Como mencionaste, su solicitará una contraseña si ya eres el usuario objetivo
• Del mismo modo, setuid (2) fallará si ya eres el usuario objetivo (en algunos sistemas operativos)
• setuid (2) no instala privilegios o controles de recursos definidos en /etc/limits.conf (Linux) o / etc / user_attr (Solaris)
• Si vas a la ruta setgid (2) / setuid (2), no olvides llamar a initgroups (3) - más sobre esto here

Generalmente uso / sbin / su para cambiar al usuario apropiado antes de iniciar los daemons.

Answer 2

Después de ver todas las sugerencias aquí, he descubierto algunas cosas que espero sean útiles para otros en mi posición:

1. está en lo correcto al señalarme en /etc/init.d/functions : la función daemon ya te permite configurar un usuario alternativo:

   daemon --user=my_user my_cmd &>/dev/null &

   Esto se implementa al envolver la invocación del proceso con el runuser , más sobre esto más adelante.

2. Jonathan Leffler tiene razón: hay setuid en Python:

   import os
   os.setuid(501) # UID of my_user is 501

   Sin embargo, todavía no creo que puedas usar setuid desde dentro de una JVM.

3. Ni runuser ni runuser manejan con gracia el caso en el que pides ejecutar un comando como el usuario que ya eres. P.ej:

   [my_user@my_host]$ id
   uid=500(my_user) gid=500(my_user) groups=500(my_user)
   [my_user@my_host]$ su my_user -c "id"
   Password: # don''t want to be prompted!
   uid=500(my_user) gid=500(my_user) groups=500(my_user)

Para solucionar ese comportamiento de su y runuser , he cambiado mi script init a algo como:

if [[ "$USER" == "my_user" ]]
then
    daemon my_cmd &>/dev/null &
else
    daemon --user=my_user my_cmd &>/dev/null &
fi

¡Gracias a todos por su ayuda!

Answer 3

En Debian usamos la utilidad start-stop-daemon , que maneja los archivos pid, cambiando el usuario, poniendo el daemon en segundo plano y mucho más.

No estoy familiarizado con RedHat, pero la utilidad daemon que ya está utilizando (que se define en /etc/init.d/functions , btw.) Se menciona en todas partes como el equivalente a start-stop-daemon , por lo que también puede cambiar el uso de su programa, o la forma en que lo hace ya es la correcta.

Si miras alrededor de la red, hay varios contenedores listos para usar que puedes usar. Algunos incluso pueden estar empaquetados en RedHat. Eche un vistazo a daemonize , por ejemplo.

Answer 4

Necesitaba ejecutar una aplicación Spring .jar como un servicio, y encontré una manera simple de ejecutar esto como un usuario específico:

Cambié el propietario y el grupo de mi archivo jar al usuario que quería ejecutar como. Luego, vinculó este frasco en init.d e inició el servicio.

Asi que:

#chown myuser:myuser /var/lib/jenkins/workspace/springApp/target/springApp-1.0.jar

#ln -s /var/lib/jenkins/workspace/springApp/target/springApp-1.0.jar /etc/init.d/springApp

#service springApp start

#ps aux | grep java
myuser    9970  5.0  9.9 4071348 386132 ?      Sl   09:38   0:21 /bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -jar /var/lib/jenkins/workspace/springApp/target/springApp-1.0.jar

Answer 5

Por qué no probar lo siguiente en el script de inicio:

setuid $USER application_name

Funcionó para mí

Answer 6

Solo para agregar algunas otras cosas para tener en cuenta:

• Sudo en un script init.d no es bueno ya que necesita un tty ("sudo: lo siento, debes tener un tty para ejecutar sudo")
• Si está demonizando una aplicación java, es posible que desee considerar Java Service Wrapper (que proporciona un mecanismo para configurar el ID de usuario)
• Otra alternativa podría ser su --session-command = [cmd] [user]

Answer 7

en una máquina virtual CENTOS (Red Hat) para el servidor svn: editó /etc/init.d/svnserver para cambiar el pid a algo que svn pueda escribir:

pidfile=${PIDFILE-/home/svn/run/svnserve.pid}

y opción agregada --user=svn :

daemon --pidfile=${pidfile} --user=svn $exec $args

El archivo pid original era /var/run/svnserve.pid . El daemon no se inició porque solo root podía escribir allí.

 These all work:
/etc/init.d/svnserve start
/etc/init.d/svnserve stop
/etc/init.d/svnserve restart

Answer 8

• Algunos daemons (por ejemplo, apache) lo hacen solos llamando a setuid()
• Puede usar el indicador de archivo setuid para ejecutar el proceso como un usuario diferente.
• Por supuesto, la solución que mencionas también funciona.

Si tiene la intención de escribir su propio daemon, entonces le recomiendo llamar a setuid (). De esta manera, su proceso puede

1. Haga uso de sus privilegios de administrador (por ejemplo, abrir archivos de registro, crear archivos pid).
2. Deja sus privilegios de root en un cierto punto durante el inicio.