Best-Practice-Linux-Service als ein anderer Benutzer laufen

Question

Dienste standardmäßig als root beim Booten auf meinem RHEL Box zu starten. Wenn ich mich richtig erinnere, ist das gleiche gilt für andere Linux-Distributionen, die den Init-Skripte in /etc/init.d verwenden.

Was denken Sie, ist der beste Weg, um die Prozesse als (statisch) Benutzer meiner Wahl ausführen, um stattdessen haben?

Die einzige Methode, die ich angekommen war an war wie etwas zu verwenden:

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

Aber das scheint ein bisschen unsauber ...

Gibt es ein wenig Magie versteckt, die einen einfachen Mechanismus liefert automatisch starten Dienste wie andere, nicht-Root-Benutzer?

EDIT: Ich habe gesagt, sollte, dass die Prozesse ich in diesem Fall beginnen, sind entweder Python-Skripte oder Java-Programme. Ich möchte lieber nicht über eine native Wrapper um sie herum, schreiben so leider nennen Ich bin nicht in der Lage setuid () wie Schwarz vermuten läßt.

Answer 1

Auf Debian wir das start-stop-daemon Dienstprogramm verwenden, die pid-Dateien verarbeitet, den Benutzer zu ändern, setzen Sie den Dämon in den Hintergrund und vieles mehr.

Ich bin nicht vertraut mit RedHat, aber das daemon Dienstprogramm, das Sie bereits verwenden (die in /etc/init.d/functions definiert ist, btw.) Wird überall als Äquivalent erwähnt start-stop-daemon, also entweder es kann auch die uid des Programms ändern oder wie Sie es tun, ist schon die richtige ist.

Wenn Sie um das Netz suchen, gibt es mehrere fertige Wrapper, die Sie verwenden können. Einige haben sogar schon werden in RedHat verpackt. Hier finden Sie aktuelle daemonize , zum Beispiel.

Answer 2

Nach einem Blick auf alle Vorschläge hier, habe ich ein paar Dinge entdeckt, die ich hoffe, auf andere in meiner Position nützlich sein:

1. Hop rechts mich zurück zu Punkt bei /etc/init.d/functions: die daemon Funktion können Sie bereits einen alternativen Benutzer eingestellt werden:

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

   Dies wird durch das Einwickeln der Umsetzung Prozessaufruf mit runuser - dazu später mehr.

2. Jonathan Leffler ist richtig: es ist in Python setuid:

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

   ich noch nicht denken, Sie können setuid aus dem Innern einer JVM, aber.

3. Weder su noch runuser graziös den Fall behandeln, in denen Sie fragen Sie einen Befehl als Benutzer ausführen zu können, bereits sind. Z.

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

, dass das Verhalten von su und runuser Umgehung Ich habe meine Init-Skript ähnlich wie folgt geändert:

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

Danke allen für Ihre Hilfe!

Answer 3

• Einige Daemons (zB Apache) tun dies, indem sich durch den Aufruf setuid ()
• könnten Sie verwenden den setuid-Datei Flagge den Prozess als ein anderer Benutzer zu laufen.
• Natürlich ist die Lösung, die Sie funktioniert auch erwähnt.

Wenn Sie Ihren eigenen Daemon zu schreiben, dann setuid- empfehle ich () aufrufen. Auf diese Weise Ihr Prozess kann

1. Nutzen Sie seine Root-Rechte (zum Beispiel offener Protokolldateien, pid-Dateien erstellen).
2. Drop seine Root-Rechte an einem bestimmten Punkt während des Startvorgangs.

Answer 4

Nur ein paar andere Dinge hinzufügen zu achten:

• Sudo in einem init.d-Skript ist nicht gut, da es eine tty ( "sudo: sorry, müssen Sie einen tty haben sudo ausführen") muss
• Wenn Sie eine Java-Anwendung sind daemonizing, können Sie Java Service Wrapper (die einen Mechanismus bereit, für die Einstellung der Benutzer-ID)
betrachten
• Eine weitere Alternative könnte sein, su --session-command = [cmd] [user]

Answer 5

auf einem CENTOS (Red Hat) virtuelle Maschine für SVN-Server: bearbeitet /etc/init.d/svnserver die pid zu etwas zu ändern, die svn schreiben:

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

und zusätzliche Option --user=svn:

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

Die ursprüngliche pidfile war /var/run/svnserve.pid. Der Daemon nicht gestartet becaseu nur root dort schreiben konnte.

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

Answer 6

Einige Dinge zu achten:

• Wie Sie erwähnt haben, so wird nach einem Passwort gefragt, wenn Sie bereits die Zielbenutzer
sind
• In ähnlicher Weise setuid (2) schlagen fehl, wenn Sie bereits die Zielbenutzer sind (auf einige OSs)
• setuid (2) installiert keine Privilegien oder Ressourcenobjekte definiert in /etc/limits.conf (Linux) oder / etc / user_attr (Solaris)
• Wenn Sie das setgid (2) / setuid (2) Weg zu gehen, vergessen Sie nicht initgroups zu nennen (3) - mehr dazu hier

ich in der Regel verwenden, / sbin / su den entsprechenden Benutzer zu wechseln, bevor Dämonen zu starten.

Answer 7

Warum die folgend im Init-Skript nicht versuchen:

setuid $USER application_name

Es funktioniert für mich.

Answer 8

Ich brauchte eine Feder .jar-Anwendung als Dienst ausgeführt werden soll, und fand eine einfache Möglichkeit, dies als einen bestimmten Benutzer ausgeführt wird:

änderte ich den Besitzer und die Gruppe meiner JAR-Datei an den Benutzer ich als laufen wollte. Dann symlinked dieses Glas in init.d und begann mit dem Service.

So:

#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