Las mejores prácticas para ejecutar servicio Linux como un usuario diferente

StackOverflow https://stackoverflow.com/questions/394984

  •  23-08-2019
  •  | 
  •  

Pregunta

defecto de los servicios a partir root como en tiempo de arranque en mi caja de RHEL. Si no recuerdo mal, lo mismo es cierto para otras distribuciones de Linux que utilizan los scripts de inicio en /etc/init.d.

¿Cuál cree usted que es la mejor manera de tener lugar los procesos se ejecutan como un usuario (estática) de mi elección?

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

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

Sin embargo, esto parece un poco desordenado ...

¿Hay algún poco de magia escondido que proporciona un mecanismo sencillo para iniciar automáticamente los servicios a los usuarios como al otro, no root?

EDIT: que debería haber dicho que los procesos que estoy empezando en este caso son o scripts de Python o programas Java. Yo prefiero no escribir una envoltura nativa alrededor de ellos, por lo que lamentablemente no soy capaz de llamar setuid () como Negro sugiere.

¿Fue útil?

Solución

En Debian se utiliza la utilidad start-stop-daemon, que maneja Pid-archivos, cambiar el usuario, poniendo el demonio en el fondo 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, por cierto.) Se menciona en todas partes como el equivalente a start-stop-daemon, así que o también puede cambiar el UID de su programa o la forma de hacer lo que ya es la correcta.

Si nos fijamos en la red, hay varios envoltorios confeccionados que se pueden utilizar. Algunos incluso pueden estar ya empaquetado en RedHat. Echar un vistazo a daemonize , por ejemplo.

Otros consejos

Después de mirar todas las sugerencias aquí, he descubierto algunas cosas que espero ser útil para otras personas en mi posición:

  1. hop es el adecuado para mí punto de volver en /etc/init.d/functions: la daemon función ya que permite para establecer un usuario alternativo: 

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

    Esto se implementa envolviendo la invocación de procesos con runuser - más sobre esto más adelante.

  2. Jonathan Leffler es correcto: Hay setuid en Python: 

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

    Todavía no creo que se pueda setuid por dentro de una JVM, sin embargo.

  3. Ni su ni runuser con gracia manejar el caso en el que pedir a ejecutar un comando como el usuario que Ya son. Por ejemplo:. 

    [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 este comportamiento de su y runuser, he cambiado de script de inicio 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!

  • Algunos demonios (por ejemplo Apache) hacer esto por sí mismos llamando setuid ()
  • Usted podría utilizar el setuid-archivo de bandera para ejecutar el proceso como un usuario diferente.
  • Por supuesto, la solución que usted ha mencionado funciona tan bien.

Si va a escribir su propio demonio, entonces yo recomiendo llamar setuid (). De esta manera, el proceso puede

  1. Hacer uso de sus privilegios de root (por ejemplo, archivos de registro abiertos, crear archivos PID).
  2. Excluir sus privilegios de root en un punto determinado durante el inicio.

Sólo para añadir algunas otras cosas a tener en cuenta:

  • Sudo en un script de init.d no es bueno, ya que necesita un TTY ( "sudo: lo siento, debe tener un TTY para ejecutar sudo")
  • Si está daemonizing una aplicación Java, es posible que desee considerar la posibilidad de Java Service Wrapper (que proporciona un mecanismo para establecer el identificador de usuario)
  • Otra alternativa podría ser su --session mando = [cmd] [usuario]

en CentOS (Red Hat) máquina virtual para el servidor SVN: /etc/init.d/svnserver editado para cambiar el pid a algo que svn puede escribir: 

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

y la opción añadida --user=svn: 

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

El pidfile original /var/run/svnserve.pid. El demonio no comenzó becaseu única raíz podría escribir allí. 

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

Algunas cosas a tener en cuenta:

  • Como se ha mencionado, Do solicitará una contraseña si ya eres usuario de destino
  • Del mismo modo, setuid (2) fallará si ya se encuentra el usuario de destino (en algunos sistemas operativos)
  • setuid (2) no se instala privilegios o los controles de recursos definidos en /etc/limits.conf (Linux) o / etc / user_attr (Solaris)
  • Si usted va la setgid (2) / setuid (2) la ruta, no se olvide de llamar initgroups (3) - más sobre esto aquí

I en general, utilizar / sbin / su para cambiar al usuario apropiado antes de iniciar demonios.

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

setuid $USER application_name

Se trabajó para mí.

que necesitaba para ejecutar una primavera .jar aplicación como un servicio, y encontré una forma sencilla de ejecutar este como un usuario específico:

He cambiado el propietario y el grupo de mi archivo JAR para el usuario quería correr tan. A continuación, un enlace simbólico en este frasco init.dy iniciado el servicio.

Así 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
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top