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

Mike Burgener mburgener at tuxinator.org
Sun Nov 13 16:20:33 CET 2005


Gaudenz Steinlin wrote:
> 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
> 
> _______________________________________________
> Linux-support mailing list
> Linux-support at lugbe.ch
> http://www.lugbe.ch/vmailman/listinfo/linux-support
Unsere Firma hat sich so eine möglichkeit der Datensicherheit auch 
überlegt, würde aber echt davon abraten, was passiert wenn z.B. auf 
Platte A geschrieben wird während A auf B Synchronisiert wird? dann hast 
du Halbfertige Daten Kopiert, Was passiert wenn Platte B oder Platte A 
während dem Sync nen Headcrash hat? dann sind die Daten auf beiden 
Platten inkonsistend und unbrauchbar, bevor man Wild drauflos geht mit 
Datensicherheit ist es wesentlich besser die verschiedenen möglichkeiten 
zu Evaluieren, alternativen währen auch Wichtige Ordner mit 
Professionellen Sync-Tools auf CD/DVD/Tape verbannen. für IDE-Platten 
bietet jedoch Software/Hardware-Raid immer noch die Beste 
Konsistenz/Sicherheit.

Aber sind alles wie gesagt nur Vorschläge.

Gruss

Mike


More information about the Linux-support mailing list