Le migliori pratiche per l'esecuzione del servizio di Linux come un altro utente

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

  •  23-08-2019
  •  | 
  •  

Domanda

Servizi di default a partire da root al momento dell'avvio sulla mia scatola di RHEL. Se ricordo bene, lo stesso vale per le altre distribuzioni Linux che utilizzano gli script di init in /etc/init.d.

Cosa pensi sia il modo migliore per avere invece i processi eseguiti come un utente (statica) di mia scelta?

L'unico metodo che avevo era arrivato a usare qualcosa come: 

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

Ma questo sembra un po 'in disordine ...

C'è qualche po 'di magia nascosto che fornisce un meccanismo semplice per l'avvio automatico dei servizi come gli utenti altri, non root?

Modifica Avrei dovuto dire che i processi sto iniziando in questo caso sono o script Python o programmi Java. Preferirei non scrivere un wrapper nativo intorno a loro, così purtroppo non riesco a chiamare setuid () come suggerisce nero .

È stato utile?

Soluzione

Su Debian si usa il programma di utilità start-stop-daemon, che gestisce pid-file, cambiare l'utente, mettendo il demone in background e molto altro ancora.

Non ho familiarità con RedHat, ma l'utilità daemon che si sta già utilizzando (che è definito in /etc/init.d/functions, btw.) È menzionato ovunque come l'equivalente di start-stop-daemon, quindi o si può anche modificare l'uid del programma , o il modo in cui lo si fa è già quella corretta.

Se si guarda intorno alla rete, ci sono diversi involucri già pronti che è possibile utilizzare. Alcuni possono anche essere già confezionati in RedHat. Dai un'occhiata alla daemonize , per esempio.

Altri suggerimenti

Dopo aver esaminato tutti i suggerimenti qui, ho scoperto un paio di cose che spero possa essere utile ad altri nella mia posizione:

  1. hop è giusto per puntare di nuovo me al /etc/init.d/functions: il Funzione daemon consente già impostare un utente alternativo: 

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

    Questa è implementato avvolgendo il invocazione di processo con runuser - più in seguito.

  2. Jonathan Leffler ha ragione: C'è setuid in Python: 

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

    io ancora non credo che si possa setuid dall'interno di una JVM, però.

  3. Né su né runuser gestire correttamente il caso in cui si chiedere di eseguire un comando come l'utente che si già sono. Per esempio:. 

    [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)

Per risolvere che il comportamento di su e runuser, ho cambiato il mio script di init a qualcosa di simile: 

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

Grazie a tutti per il vostro aiuto!

  • Alcuni demoni (ad esempio Apache) fanno da soli chiamando setuid ()
  • È possibile utilizzare il setuid file bandiera per eseguire il processo come un altro utente.
  • Naturalmente, la soluzione che lei ha citato funziona pure.

Se avete intenzione di scrivere il proprio demone, poi mi consiglia di chiamare setuid (). In questo modo, il processo può

  1. Fare uso dei propri privilegi di root (per esempio i file di log aperti, creare file PID).
  2. Goccia suoi privilegi di root a un certo punto durante l'avvio.

Giusto per aggiungere alcune altre cose a cui fare attenzione:

  • Sudo in uno script init.d non va bene in quanto ha bisogno di un terminale ( "sudo: mi dispiace, è necessario disporre di un terminale per eseguire sudo")
  • Se si daemonizing un'applicazione Java, si potrebbe prendere in considerazione Java Servizio Wrapper (che fornisce un meccanismo per impostare l'id utente)
  • Un'altra alternativa potrebbe essere su --session-comando = [cmd] [utente]

su un CENTOS (Red Hat) macchina virtuale per server SVN: /etc/init.d/svnserver modificato per cambiare il pid a qualcosa che svn può scrivere: 

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

e ha aggiunto l'opzione --user=svn: 

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

Il pidfile originale era /var/run/svnserve.pid. Il demone non è stato avviato becaseu solo root potrebbe scrivere lì. 

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

Alcune cose da guardare fuori per:

  • Come lei ha ricordato, su chiederà una password se sei già l'utente di destinazione
  • Allo stesso modo, setuid (2) avrà esito negativo se sei già l'utente di destinazione (su alcuni sistemi operativi)
  • setuid (2) non installa privilegi o controlli delle risorse definite in /etc/limits.conf (Linux) o / etc / user_attr (Solaris)
  • Se si va il setgid (2) / setuid (2) percorso, non dimenticare di chiamare initgroups (3) - più su questo qui

Generalmente uso / sbin / su per passare all'utente appropriato prima di avviare daemon.

Perché non provare la seguente nello script di init: 

setuid $USER application_name

Ha funzionato per me.

Avevo bisogno di eseguire una primavera .jar applicazione come un servizio, e ha trovato un modo semplice per eseguire questo come un utente specifico:

Ho cambiato il proprietario e il gruppo del mio file jar per l'utente che volevo per l'esecuzione come. Poi link simbolico questo barattolo in init.d e avviato il servizio. 

#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
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top