[linux-support] Backup Script in Ubuntu mit root Rechten laufen lassen

Gaudenz Steinlin gaudenz at soziologie.ch
Sun Nov 13 16:05:36 CET 2005


On Sun, Nov 13, 2005 at 01:31:50PM +0100, Philipp Sury wrote:
> Stefan Haller wrote:
> > Dies ist aus
> > Sicherheitsgründen so, da es relativ einfach ist über ein setuid-root
> > shellscript zu einer root shell zu kommen.
> 
> Das macht Sinn.
> 
> > Ich verstehe nicht, wieso du dein script nicht mit sudo startest (z.B.
> > sudo /root/script). So kannst du das gut testen bis Du das in der
> > crontab eingetragen hast.
> 
> Das kann ich, dann muss ich aber auch alle Befehle innerhalb des Scripts
> mit sudo versehen, sonst gibt es das genannte Problem.

Dann machst du definitiv noch etwas falsch. Ich vermute mal, dass das
nichts mit den Rechten zu tun hat, sondern einfach an deinem Skript
liegt. Wenn du das Skript mit sudo startest, dann läuft es mit UID 0
(root) und das gilt auch für alle Prozesse, die das Skript startet.

> 
> Mir ist noch nicht ganz klar, warum die crontab dann später ohne sudo
> auskommt, aber ich brav sudo eintippen muss. Bisher bin ich immer davon
> ausgegangen "was root gehört, darf alles" und der Inhalt von /bin z.B.
> gehört ja root.
Zuerst zu cron: Cron läuft ja bereits als root. Es kann also weitere
Prozesse (z.B. die Cronjobs) als root starten. Also hier ist kein
Problem.
Ich glaube dir ist noch nicht ganz klar, wie das sudo/root Konzept von
Ubuntu aussieht. Der root Account auf einem Ubuntu System existiert
genauso wie auf jedem anderen System auch. Er hat einfach ein
deaktiviertes Passwort. Das hindert aber Daemons (wie cron) nicht daran
als root zu laufen und sie benötigen dazu auch nicht sudo. Sudo brauchst
du nur, wenn du als Benutzer etwas als mit root-Rechten laufen lassen
willst. Der einzige Unterschied zwischen Ubuntu und einem "normalen"
Linux Installation ist, dass du nicht also root einloggen kannst und
dass du den Befehl su nicht benutzen kannst. Beides kannst du aber auch
unter Ubuntu einfach ermöglichen, in dem du "sudo passwd" ausführst und
dem root Account ein Passwort gibst.
Das root Konzept von OS X ist im übrigen genau gleich wie jenes von
Ubuntu.

Nun noch zum "was root gehört, darf alles": Hier vermischt du die
Dateisystemrechte einer ausführbaren Datei mit den Rechten eines
laufenden Prozesses. Beides hat (abgesehen von setuid) eigentlich nichts
miteinander zu tun. Egal wem eine ausführbare Datei gehört, erbt der
Prozess, welcher entsteht wenn du sie ausführst immer die Rechte des
Prozesses aus welchem er gestartet wurde. Also zum Beispiel die Rechte
der Shell, wenn du einen Befehl auf der Shell eintippst. Das gesetzte
setuid Bit ändert dieses verhalten. Dann bekommt der neue Prozess die
Rechte des Owners der Binärdatei im Dateisystem. Z.B. sudo hat das
setuid Bit gesetzt, da es als root laufen muss, um seine Funktion zu
erfüllen.

> 
> Liegt des Rätsels Lösung also darin, dass der cronjob mit dem passenden
> setuid-but ausgeführt wird und somit dessen Rechte automatisch auch für
> das aktivierte Script gelten, während das Script alleine diese Rechte
> offenbar gar nicht haben kann?

Nein ein cron job mit setuid bit ist praktisch in jedem fall eine
fehlkonfiguration. Der job erbt die Rechte vom cron daemon, welcher ihn
startet und kann damit also root laufen. Bei Jobs in crontabs von
Benutzern gibt cron seine root Rechte "freiwillig" auf und setzt die
Rechte des Jobs auf die Rechte des Benutzers zu dem der Job gehört. Das
kann cron, weil es als root läuft. 

So das wurde ja nun ein richtiger Crashkurs in Unix Prozessrechten.

Gruss Gaudenz



More information about the Linux-support mailing list