2009-06-11 13 views
0

Ich brauche eine Möglichkeit, das os.system() -Modul als unterschiedliche UIDs auszuführen. Es wäre ähnlich der folgenden BASH-Code verhalten müssen (beachten Sie diese sind nicht die genauen Befehle, die ich ausführen bin):Ausführen von Shell-Befehlen als UID in Python

su user1 
ls ~ 
mv file1 
su user2 
ls ~ 
mv file1 

Die Zielplattform GNU Linux generisch ist.

Natürlich könnte ich diese nur an das os.system-Modul übergeben, aber wie das Passwort zu senden? Natürlich könnte ich das Skript als root ausführen, aber das ist schlampig und unsicher.

Vorzugsweise möchte ich damit umgehen, ohne dass Passwörter im Klartext vorliegen müssen.

+0

David Cournapeau und Michiel Buddingh hatten beide gute Seiten. Ich werde die Funktion os.seteuid() zusammen mit einem privilegierten Benutzer (nicht root) verwenden, um das Skript auszuführen. – Caedis

Antwort

1

Die Funktion, nach der Sie suchen, heißt os.seteuid. Ich fürchte, Sie werden wahrscheinlich das Skript nicht als root ausführen, aber ich denke, Sie können das capabilities(7) Framework verwenden, um die Ausführung ein wenig einzugrenzen, so dass es Benutzer ändern kann - aber nicht irgendwelche der anderen Dinge, die der Superuser kann.

Alternativ können Sie möglicherweise in der Lage sein, dies mit PAM zu tun. Aber im Allgemeinen gibt es keine "nette" Möglichkeit, dies zu tun, und David Cournapeau hat absolut recht, dass es für Admin-Skripte üblich ist, mit Privilegien zu laufen.

+0

@Vye Dies war kein Tippfehler, bitte unterlassen Sie schädliche Änderungen – Erbureth

+0

Guter Fang, tut mir leid. – Vye

3

Ich denke, das ist nicht trivial: Sie können das mit einer Shell tun, weil jeder Befehl in seinen eigenen Prozess gestartet wird, der seine eigene ID hat. Aber bei Python hat alles die UID des Python-interpretierten Prozesses (vorausgesetzt, Sie starten keine Unterprozesse mit dem Subprozess-Modul und co). Ich kenne keine Möglichkeit, den Benutzer eines Prozesses zu ändern - ich weiß nicht, ob das überhaupt möglich ist - selbst wenn, würden Sie zumindest Administratorrechte benötigen.

Was versuchst du genau zu machen? Das klingt zum Beispiel nicht nach dem richtigen Zweck für Admin-Zwecke. Im Allgemeinen laufen Admin-Skripte in einem privilegierten Benutzer - denn niemand kennt das Passwort von Benutzer 2 außer Benutzer 2 (theoretisch). Da root bedeutet, dass su Benutzer immer für einen "normalen" Benutzer arbeiten, ohne ein Passwort anzufordern.

+0

Ihr Recht, es macht mehr Sinn, nur einen privilegierten Benutzer zu erstellen, der das Skript mit bestimmten erhöhten Rechten ausführen kann. Eine sauberere Lösung als die Ausführung als root. – Caedis

2

vielleicht können sudo Ihnen dabei helfen, sonst müssen Sie root sein os.setuid

alternativ ausführen, wenn Sie Spaß haben wollen Sie pexpect verwenden können Dinge , so etwas zu tun, können Sie über diese

verbessern
1

Irgendwo auf der Linie wird ein Prozess oder andere eine effektive UID von 0 (Root) benötigen, weil nur ein solcher Prozess die effektive UID auf eine beliebige andere UID setzen kann.

Bei der Shell ist der Befehl su ein SUID-Root-Programm; es ist entsprechend privilegiert (POSIX-Jargon) und kann die echte und effektive UID setzen. In ähnlicher Weise kann der Befehl sudo den gleichen Job ausführen. Mit sudo können Sie auch konfigurieren, welche Befehle und UID zulässig sind. Der entscheidende Unterschied ist, dass su das Passwort des Zielbenutzers benötigt, um Sie einzulassen; sudo erfordert das Passwort des Benutzers, der es ausführt.

Es gibt natürlich die Frage, ob ein Benutzer die Kennwörter anderer Benutzer kennen sollte. Im Allgemeinen sollte kein Benutzer das Passwort eines anderen Benutzers kennen.

Scripting UID Änderungen ist schwer.Sie tun können:

su altuser -c "commands to execute as altuser" 
sudo -u altuser commands to execute as altuser 

jedoch su ein Passwort von dem Steuerterminal verlangen (und wird scheitern, wenn es kein Steueranschluss ist). Wenn Sie sudo verwenden, werden die Anmeldeinformationen zwischengespeichert (oder können dafür konfiguriert werden), so dass Sie nur einmal nach einem Kennwort gefragt werden - aber es wird beim ersten Mal wie bei su angezeigt.

Arbeiten um die Aufforderung ist schwer. Sie können Werkzeuge parallel zu expect verwenden, die Pseudo-ttys für Sie behandeln. Sie werden dann jedoch damit konfrontiert, Kennwörter in Skripten zu speichern (keine gute Idee) oder sie irgendwie außer Sichtweite zu halten.


Das Werkzeug, das ich für den Job verwenden ist ich schrieb, genannt asroot. Dadurch kann ich genau die UID- und GID-Attribute steuern, die der untergeordnete Prozess haben sollte. Aber es ist so konzipiert, dass ich es nur benutzen darf - das heißt, zur Kompilierzeit wird der berechtigte Benutzername angegeben (natürlich kann das geändert werden). Allerdings kann ich Dinge wie:

asroot -u someone -g theirgrp -C -A othergrp -m 022 -- somecmd arg1 ... 

Dadurch wird die reale und effektive UID zu ‚jemand‘ setzt, setzt die primäre Gruppe ‚theirgrp‘, entfernt alle Hilfsgruppen und fügt hinzu ‚othergrp‘ (so den Prozess gehört zu nur zwei Gruppen) und setzt die Umask auf 0222; Es führt dann 'somecmd' mit den angegebenen Argumenten aus.

Für einen bestimmten Benutzer, der eingeschränkten (oder nicht so begrenzten) Zugriff auf andere Benutzerkonten benötigt, funktioniert das gut. Als allgemeine Lösung ist es nicht so heiß; sudo ist in den meisten Punkten besser, erfordert aber immer noch ein Passwort (was asroot nicht tut).

Verwandte Themen