Ausführen von Upstart-Jobs als nicht privilegierte Benutzer

Wie kann ein Startjob auf kanonische Weise seine Benutzer-ID ändern und das Skript als nicht privilegierter Benutzer ausführen?

Offensichtlich kann man suoder verwenden sudo, aber dies scheint schwierig zu sein (und kann unnötige Protokollzeilen erzeugen).

Mit Upstart v1.4 werden setuid und setgid in der Konfigurationsdatei nativ unterstützt.

Auf dem #upstart-Kanal bei freenode lautet die offizielle Meinung dazu:

Eine zukünftige Version von Upstart wird diesbezüglich native Unterstützung bieten. Sie können jedoch vorerst Folgendes verwenden:

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

Wie wäre es mit Start-Stop-Daemon?

exec start-stop-daemon --start --chuid daemonuser --exec /bin/server_cmd

Aus dem Upstart-Kochbuch :

Die empfohlene Methode für Debian- und Ubuntu-Systeme ist die Verwendung des Hilfsprogramms start-stop-daemon. […] start-stop-daemonBeschränkt den Prozess, den es startet, nicht auf PAM ("Pluggable Authentication Module").

Hinweis: start-stop-daemonWird in RHEL nicht unterstützt.

Es gibt verschiedene Methoden, die alle leicht unterschiedliche Semantiken haben, insbesondere in Bezug auf die Gruppenzugehörigkeit:

• setuidgid Sie werden in die von Ihnen angegebene Gruppe aufgenommen.

  • Mit den ursprünglichen Daemontools setuidgidwerden Sie nur in diese Gruppe aufgenommen, sodass Sie nicht auf Dateien zugreifen können, die zu anderen Gruppen gehören, denen Sie angehören.
  • Die setuidgidvon daemontools-Zugabe und die setuidgidvon der nosh Toolset beide eine -s(aka --supplementary) Option , die Sie in dieser Gruppe setzen, und Sie auch in all den gestellten zusätzlichen Gruppen für den Benutzer , die Sie angeben.

• Wenn newgrpSie "Sobald Sie der Benutzer mit den geringsten Berechtigungen sind" verwenden, wird eine einzelne Gruppe zu Ihrer Gruppe hinzugefügt, es wird jedoch auch eine neue Subshell erstellt, was die Verwendung in Skripten erschwert.

• start-stop-daemon Erhält Ihre Gruppenzugehörigkeit und leistet viel mehr als nur setuid / setgid.

• chpst -u username:group1:group2:group3... commandnameDamit können Sie genau festlegen, welche Gruppenmitgliedschaften übernommen werden sollen, aber (in Ubuntu ) ist nur das runitPaket enthalten, das eine Alternative zu upstart.

• su -c commandname usernamenimmt alle Gruppenmitgliedschaften des Benutzernamens auf sudo -u username commandname, so wie es der Fall ist , also sind sie wahrscheinlich der Weg zu geringstem Erstaunen.

Verwenden Sie setuidgidaus der Packung daemontools.

Dokumentation hier: http://cr.yp.to/daemontools/setuidgid.html

Auf einer Ubuntu 10.10-Instanz unter Amazon EC2 hatte ich mit dem start-stop-daemonBefehl mehr Glück .

Ich kämpfte auch mit einigen der anderen Emporkömmling Strophen . Ich rufe eine Python-Anwendung mit einem bestimmten virtualenvParameter für mein ausgeführtes Programm auf.

Folgendes hat bei mir funktioniert.

script
  export PYTHONPATH=.:/home/ubuntu/.local/lib/python2.7/site-packages/:/home/ubuntu/python/lib/python2.7/site-packages/
  exec start-stop-daemon --start  --chuid ubuntu --exec /home/ubuntu/python_envs/MyProj/bin/python /home/ubuntu/www/MyProj/MyProj.py -- --config-file-dir=/home/ubuntu/www/MyProj/config/ >> /home/ubuntu/startup.log 2>&1 &
end script

Damit werden PYTHONPATHeinige Pakete von der Quelle in den PYTHON-Modulpfad installiert, wenn dieser Startjob ausgeführt wird. Ich musste alles in absoluten Pfaden tun, weil die chdirStrophe nicht zu funktionieren schien.

Ich habe CentOS 6 verwendet und konnte weder den empfohlenen Hack (für Upstart 0.6.5) für mich zum Laufen bringen, noch den 'su'-Trick, weil die Anzahl der beteiligten Gabeln (4, glaube ich) nicht von' expect fork 'erfasst wurde 'oder' Daemon erwarten '.

Ich habe es irgendwann einfach getan

chown user:group executable
chmod +s executable

(dh setuid setzen und Eigentümer ändern).

Es ist vielleicht nicht die sicherste Methode, aber für ein internes F & E-Projekt war das in unserem Fall egal.

Es gibt eine dritte Möglichkeit, je nachdem, was Sie erreichen möchten. Möglicherweise können Sie die Zugriffskontrollen für die betreffenden Dateien / Geräte lösen . Dies kann es einem nicht privilegierten Benutzer ermöglichen, Elemente bereitzustellen oder auf diese zuzugreifen, die normalerweise nicht zulässig sind. Stellen Sie sicher, dass Sie dabei nicht die Schlüssel zum Königreich verraten.

Sie können auch das Timeout des sudo-Passwort-Cache ändern . Aber ich empfehle es nicht, es sei denn, Ihr Computer ist physisch sicher (dh Sie glauben, dass es unwahrscheinlich ist, dass ein Passant versuchen würde, Sudo-Zugriff zu erhalten).

Es gibt einen guten Grund dafür, dass es nur sehr wenige Möglichkeiten gibt, privilegierte Aktionen auszuführen, und dass sie unnötig notwendige Protokollierungen durchführen. Lose Einschränkungen stellen ein Sicherheitsrisiko für Ihr System dar, und ein Mangel an Protokollierung bedeutet, dass Sie nicht wissen können, was passiert ist, wenn Sie kompromittiert wurden.

Wenn die Größe Ihrer Protokolldateien ein Problem darstellt, stimmt wahrscheinlich etwas nicht. Sudo generiert unter normalen Bedingungen nur eine Zeile pro Verwendung.

In CentOS 6, ab Version 0.6.5, hat Folgendes für mich funktioniert.

script

    exec su user_name << EOF
        exec /path/to/command [parameters...]
EOF

end script

oder :

script

    exec su user_name << EOF
       ..... what you want to do ....
EOF

end script

Wenn verwenden

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

Der Auftragsprozess kann nicht abgebrochen werden initclt stop. Ich denke der Grund ist:

1. the job forked and the main process is not tracked.
2. the main process changed its process group,because of `su -c`