Rechte im Skript, das von procmail gestartet
Hallo, unter welchen Rechten läuft ein von procmail gestartetes Skript? Okay, unter dem Namen des Owner des Skriptes, aber die REchte des Owners hat es wohl nicht: procmail startet in /home/gerlach/.procmailrc :0 H * Subject: test | /usr/local/bin/myskript das Skript myskript: (-rwxr-xr-x 1 gerlach users 613 Feb 25 19:02 myskript) #!/bin/sh /usr/bin/whoami > /tmp/pwd echo "Hallo" > /dev/tty10 sudo /usr/sbin/isdnctrl dial ippp0 exit 0 whoami gibt "gerlach" aus. Die Ausgabe auf /dev/tty10 funktioniert nicht : /dev/tty10: Permission denied obwohl ich als user gerlach das vom x-terminal das sehr wohl darf (gerlach ist in der Gruppe tty). Des weiteren funktioniert isdnctrl dial ippp0 nur wenn ein sudo davorsteht, auch wenn isdnctrl für gerlach über /etc/sudoers freigeben. Das Skript scheint nur teilweise unter dem user gerlach abzulaufen. Warum? Bin Anfänger in dieser Frage. Hat mir jemand ein Howto / Tutorial dafür? thx Ekkard
* Ekkard Gerlach schrieb am 25.Feb.2002:
unter welchen Rechten läuft ein von procmail gestartetes Skript? Okay, unter dem Namen des Owner des Skriptes,
Wie kommst Du darauf? Natürlich nicht. Ein Skript beachtet nicht das SUID-Bit, und läuft daher *nicht* unter dem Namen des Besitzers, es sei den, derjenige, der es ausführt ist zufällig im ihm identisch. Das Skript läuft unter dem, der es ausführt. In diesem Falle also unter dem gleichen, wie derjenige, der auch procmail ausführt.
aber die REchte des Owners hat es wohl nicht:
Doch.
procmail startet in /home/gerlach/.procmailrc
:0 H * Subject: test | /usr/local/bin/myskript
das Skript myskript: (-rwxr-xr-x 1 gerlach users 613 Feb 25 19:02 myskript)
Darf jeder ausführen, also auch procmail, egal unter welchem User.
#!/bin/sh /usr/bin/whoami > /tmp/pwd echo "Hallo" > /dev/tty10 sudo /usr/sbin/isdnctrl dial ippp0 exit 0
whoami gibt "gerlach" aus. Die Ausgabe auf /dev/tty10 funktioniert nicht : /dev/tty10: Permission denied obwohl ich als user gerlach das vom x-terminal das sehr wohl darf (gerlach ist in der Gruppe tty). Des weiteren funktioniert isdnctrl dial ippp0 nur wenn ein sudo davorsteht, auch wenn isdnctrl für gerlach über /etc/sudoers freigeben. Das Skript scheint nur teilweise unter
So funktioniert sudo. Da muß ein sudo davor, wie sonst könnte sudo funktionieren? Was heißt freigegeben? Wenn etwas in der /etc/sudoers steht, dann kann man es mit sudo aufrufen, wenn es da nicht steht, dann nützt einem ein sudo nichts. Ohne sudo geht es nicht, denn wie sonst könnte sudo da eingreifen, das ist doch kein Dämon, und ich wüßte auch nicht, wie ein solcher Dämon funktionieren könnte.
dem user gerlach abzulaufen. Warum?
Was sagt denn id? Welche Gruppe? Wieso nimmst Du nicht einfach /dev/tty11 oder /dev/tty12? /dev/tty10 ist doch schon belegt mit den Systemmeldungen. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Hallo Bernd, * Bernd Brodesser schrieb:
* Ekkard Gerlach schrieb am 25.Feb.2002:
unter welchen Rechten läuft ein von procmail gestartetes Skript? Okay, unter dem Namen des Owner des Skriptes,
Wie kommst Du darauf?
Weil whoami -> gerlach ausgibt, siehe unten.
Natürlich nicht. Ein Skript beachtet nicht das SUID-Bit, und läuft daher *nicht* unter dem Namen des Besitzers, es sei den, derjenige, der es ausführt ist zufällig im ihm identisch.
Das Skript läuft unter dem, der es ausführt. In diesem Falle also unter dem gleichen, wie derjenige, der auch procmail ausführt.
Und wer ist procmail ? Welcher user? Habe Suse 7.2, weiß Du es? Ich weiß nur, daß fetchmail das procmail anstößt und fetchmail läuft als user "egerl" bei mir. Läuft dann auch procmail als user "egerl"? (Die Frage mag dumm klingen, aber ich weiß es wirklich nicht! Irgendein Howto, man-Seite oder so parat ? Man sudo kenne ich und verstehe es halbwegs. Allerdings stehen da keine Zusammenhänge mit Skripten, die von ?? getartet wurden.)
aber die REchte des Owners hat es wohl nicht:
Doch.
warum gibt dann whoami -> gerlach aus? Wenn ich den Owner des Skriptes auf einen anderen user "Testuser" setze, dann ist whoami -> "Testuser". Deshalb habe ich darauf geschlossen. Habe mich allerdings auch schon gewundert, wie ein procmail Prozess einfach so die Rechte von gerlach oder Testuser ergreifen kann.
procmail startet in /home/gerlach/.procmailrc
:0 H * Subject: test | /usr/local/bin/myskript
das Skript myskript: (-rwxr-xr-x 1 gerlach users 613 Feb 25 19:02 myskript)
Darf jeder ausführen, also auch procmail, egal unter welchem User.
#!/bin/sh /usr/bin/whoami > /tmp/pwd
^^^^^^^--- das gibt den Namen des owners des Skriptes aus.
echo "Hallo" > /dev/tty10 sudo /usr/sbin/isdnctrl dial ippp0 exit 0
whoami gibt "gerlach" aus. Die Ausgabe auf /dev/tty10 funktioniert nicht : /dev/tty10: Permission denied obwohl ich als user gerlach das vom x-terminal das sehr wohl darf (gerlach ist in der Gruppe tty). Des weiteren funktioniert isdnctrl dial ippp0 nur wenn ein sudo davorsteht, auch wenn isdnctrl für gerlach über /etc/sudoers freigeben. Das Skript scheint nur teilweise unter
So funktioniert sudo. Da muß ein sudo davor, wie sonst könnte sudo funktionieren?
Woher weiß sudo dann, daß er die Superuserrechte, die nur gerlach an isdnctrl hat, benutzen darf? Davon, daß gerlach der owner des Skriptes ist?
Was heißt freigegeben?
Mein Terminus ist in dieser Hinsicht das eines totalen Anfängers.
Wenn etwas in der /etc/sudoers steht, dann kann man es mit sudo aufrufen, wenn es da nicht steht, dann nützt einem ein sudo nichts. Ohne sudo geht es nicht, denn wie sonst könnte sudo da eingreifen, das ist doch kein Dämon, und ich wüßte auch nicht, wie ein solcher Dämon funktionieren könnte.
Warum kann ich als user gerlach an einem blanken x-Term isdnctrl aufrufen, auch ohne sudo davor?
dem user gerlach abzulaufen. Warum?
Was sagt denn id? Welche Gruppe?
Urps! Was ist id? Schon häufig von gehört ... hmmmmm. Die Gruppe ist "users", siehe oben. Was meist Du? (Sorry, ich will niemanden nerven, weißt Du ein Howto, Tutorial, ..., nach welchen Stichworten könnte ich nach threads im Archiv suchen, um x-male geführte Diskussionen dazu nachzulesen ?)
Wieso nimmst Du nicht einfach /dev/tty11 oder /dev/tty12? /dev/tty10 ist doch schon belegt mit den Systemmeldungen.
Klar, warum nicht. Ich will nur zu debugging-Zwecken Ausgaben erzeugen. thx Ekkard
Hallo Ekkard, * Ekkard Gerlach schrieb am 27.Feb.2002:
* Bernd Brodesser schrieb:
* Ekkard Gerlach schrieb am 25.Feb.2002:
unter welchen Rechten läuft ein von procmail gestartetes Skript? Okay, unter dem Namen des Owner des Skriptes,
Wie kommst Du darauf?
Weil whoami -> gerlach ausgibt, siehe unten.
Mach mal id, der gibt mehr aus. Kann ja sein, daß der Prozeß und die Datei die gleiche UID haben. Aber das rührt nicht daher, sondern ist mehr oder weniger Zufall.
Natürlich nicht. Ein Skript beachtet nicht das SUID-Bit, und läuft daher *nicht* unter dem Namen des Besitzers, es sei den, derjenige, der es ausführt ist zufällig im ihm identisch.
Das Skript läuft unter dem, der es ausführt. In diesem Falle also unter dem gleichen, wie derjenige, der auch procmail ausführt.
Und wer ist procmail ? Welcher user? Habe Suse 7.2, weiß Du es?
Nö, woher soll ich wissen, wer bei Dir procmail aufruft. Ich mache das per fetchmail.
Ich weiß nur, daß fetchmail das procmail anstößt und fetchmail läuft als user "egerl" bei mir. Läuft dann auch procmail als user "egerl"?
Ich schätze mal schon. Bei mir haben weder procmail noch fetchmail das SUID-Bit gesetzt. Dann würde es umgebogen auf deren Besitzer. Das sind nämlich Programme und keine Skripts. Kann natürlich auch ganz fieß da irgendetwas fest einprogrammiert sein, kann aber nur funktionieren, wenn es als root läuft. Da aber kein SUID gesetzt ist und Du es nicht als root aufrufst kann es auch das nicht sein. Wäre aber auch sehr ungewöhnlich, sowas macht eigentlich nur init.
(Die Frage mag dumm klingen, aber ich weiß es wirklich nicht! Irgendein Howto, man-Seite oder so parat ? Man sudo kenne ich und verstehe es halbwegs. Allerdings stehen da keine Zusammenhänge mit Skripten, die von ?? getartet wurden.)
Das Skript wird immer als denjenigen ausggeführt, der es gestartet hat. Genauer, die shell, die das Skript ausführt, hat den gleichen realen und effektiven UID wie der aufrufende Prozess.
aber die REchte des Owners hat es wohl nicht:
Doch.
warum gibt dann whoami -> gerlach aus? Wenn ich den Owner des Skriptes auf einen anderen user "Testuser" setze, dann ist whoami -> "Testuser". Deshalb habe ich darauf geschlossen. Habe mich allerdings auch schon gewundert, wie ein procmail Prozess einfach so die Rechte von gerlach oder Testuser ergreifen kann.
Das wäre der typische Fall, wenn das SUID-Bit des Skriptes gesetzt wäre, nur bei Skripten funktioniert das SUID-Bit nicht. Also auch wenn es gesetzt ist, nutzt es nichts. Vielleicht macht whoami ja Mist.
procmail startet in /home/gerlach/.procmailrc
:0 H * Subject: test | /usr/local/bin/myskript
das Skript myskript: (-rwxr-xr-x 1 gerlach users 613 Feb 25 19:02 myskript)
Darf jeder ausführen, also auch procmail, egal unter welchem User.
#!/bin/sh /usr/bin/whoami > /tmp/pwd ^^^^^^^--- das gibt den Namen des owners des Skriptes aus.
echo "Hallo" > /dev/tty10 sudo /usr/sbin/isdnctrl dial ippp0 exit 0
whoami gibt "gerlach" aus. Die Ausgabe auf /dev/tty10 funktioniert nicht : /dev/tty10: Permission denied obwohl ich als user gerlach das vom x-terminal das sehr wohl darf (gerlach ist in der Gruppe tty). Des weiteren funktioniert isdnctrl dial ippp0 nur wenn ein sudo davorsteht, auch wenn isdnctrl für gerlach über /etc/sudoers freigeben. Das Skript scheint nur teilweise unter
So funktioniert sudo. Da muß ein sudo davor, wie sonst könnte sudo funktionieren?
Woher weiß sudo dann, daß er die Superuserrechte, die nur gerlach an isdnctrl hat, benutzen darf? Davon, daß gerlach der owner des Skriptes ist?
Nein, weil es so im /etc/sudoers eingetragen hast. Vielleicht hast Du auch ALL eingetragen und der User darf dann alle Superuserbefehle mit einem sudo davor ausführen. Ein NOPASSWD wirst Du ihm auch mitgegeben haben, sonst hätte er ja nach dem Passwort gefragt. Hat nichts damit zu tun, wem die Datei gehört. Wem eine Datei gehört ist irrelevant, außer das SUID-Bit ist gesetzt und für wem welche Rechte zählen, aber wenn so wie so alle ausführen dürfen, ist es für die Ausführung irrelevant. Es wird immer mit der UID dessen ausgeführt, der es aufruft. Besser gesagt des Prozesses, der aufruft.
Was heißt freigegeben?
Mein Terminus ist in dieser Hinsicht das eines totalen Anfängers.
Wenn etwas in der /etc/sudoers steht, dann kann man es mit sudo aufrufen, wenn es da nicht steht, dann nützt einem ein sudo nichts. Ohne sudo geht es nicht, denn wie sonst könnte sudo da eingreifen, das ist doch kein Dämon, und ich wüßte auch nicht, wie ein solcher Dämon funktionieren könnte.
Warum kann ich als user gerlach an einem blanken x-Term isdnctrl aufrufen, auch ohne sudo davor?
Welche Rechte hat isdnctrl? Und der user gerlach hat doch nicht etwa die UID 0?
dem user gerlach abzulaufen. Warum?
Was sagt denn id? Welche Gruppe?
Urps! Was ist id? Schon häufig von gehört ... hmmmmm. Die Gruppe ist "users", siehe oben. Was meist Du? (Sorry, ich will niemanden nerven, weißt Du ein Howto, Tutorial, ..., nach welchen Stichworten könnte ich nach threads im Archiv suchen, um x-male geführte Diskussionen dazu nachzulesen ?)
Wieso nerven? Mach einfach mal id, anstelle von whoami. id gibt mehr Sachen aus.
Wieso nimmst Du nicht einfach /dev/tty11 oder /dev/tty12? /dev/tty10 ist doch schon belegt mit den Systemmeldungen.
Klar, warum nicht. Ich will nur zu debugging-Zwecken Ausgaben erzeugen.
/dev/tty10 würde ich nicht durcheinanderwerfen. Die Ausgabe läßt sich über /etc/syslog.conf steuern. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
Hallo,
Ekkard Gerlach: unter welchen Rechten läuft ein von procmail gestartetes Skript?
Wenn ich das link verstehe, dann läuft procmail mehrfach unter verschiedenen Rechten. In einer Standard-Suse-ohne-anfassen-Installation ist procmail ja schon mit eingehängt. Dann ist es wohl so, daß er über _jede_ nachricht procmail als root laufen lässt, unter Verwendung der (normalerweise nicht existierenden) Datei /etc/procmailrc (Kein Punkt!). Da diese Datei i.d.R. nicht existiert, fällt das weg. ;-) Außerdem läuft procmail, wenn die Mail für einen lokalen User ist, nochmal mit den Einstellungen aus ~/.procmailrc (Mit Punkt!), und zwar "als" dieser User.
Okay, unter dem Namen des Owner des Skriptes,
Wie kommst Du darauf?
Weil whoami -> gerlach ausgibt, siehe unten.
Das ist nicht richtig und nicht falsch. :-) Der zweite Durchlauf findet mit der Identität des Empfängers statt. Daß das "gerlach" ist, liegt nicht daran, daß das Script "gerlach" gehört, sondern daß die Mail an "gerlach" gerichtet war, daher procmail als "gerlach" mit der .procmailrc im Ordner /home/gerlach/ ausgeführt wird. Wie procmail an deine Identität kommt? Weil es ursprünglich als root läuft und daher auf die User "runterschalten" kann, ohne das Passwort zu kennen. Wenn du als root mal eingibst su gerlach , bist du sofort User "gerlach", ohne daß du nach einem Passwort gefragt würdest. Gruß, Ratti
Hallo Ratti, * Ratti schrieb:
Hallo,
Ekkard Gerlach: unter welchen Rechten läuft ein von procmail gestartetes Skript?
Wenn ich das link verstehe, dann läuft procmail mehrfach unter verschiedenen Rechten.
In einer Standard-Suse-ohne-anfassen-Installation ist procmail ja schon mit eingehängt. Dann ist es wohl so, daß er über _jede_ nachricht procmail als root laufen lässt, unter Verwendung der (normalerweise nicht existierenden) Datei /etc/procmailrc (Kein Punkt!).
Da diese Datei i.d.R. nicht existiert, fällt das weg. ;-)
richtig, sie ex. nicht.
Außerdem läuft procmail, wenn die Mail für einen lokalen User ist, nochmal mit den Einstellungen aus ~/.procmailrc (Mit Punkt!), und zwar "als" dieser User.
habe eigene .procmailrc in /home/gerlach/.procmailrc
Okay, unter dem Namen des Owner des Skriptes,
Wie kommst Du darauf?
Weil whoami -> gerlach ausgibt, siehe unten.
Das ist nicht richtig und nicht falsch. :-)
Der zweite Durchlauf findet mit der Identität des Empfängers statt. Daß das "gerlach" ist, liegt nicht daran, daß das Script "gerlach" gehört, sondern daß die Mail an "gerlach" gerichtet war, daher procmail als "gerlach" mit der .procmailrc im Ordner /home/gerlach/ ausgeführt wird.
Einspruch: wenn ich dem Skript den owner "egerl" gebe, an den niemals mails gerichtet sind und der keine .procmailrc hat, dann gibt whoami oder id aus owner auch egerl mit seiner ID 501 aus, siehe meine Antwortmail auf Bernd, die sich mit Deiner überschnitten hat.
Wie procmail an deine Identität kommt? Weil es ursprünglich als root läuft und daher auf die User "runterschalten" kann, ohne das Passwort zu kennen.
hmmmm - hmmm .. und orientiert sich an dem owner des Skriptes.
Wenn du als root mal eingibst su gerlach , bist du sofort User "gerlach", ohne daß du nach einem Passwort gefragt würdest.
ok. Jetzt sag mit noch, warum ich im Skript nicht auf /dev/tty11 schreiben darf, obwohl gerlach in der Gruppe tty ist und von einem xterm das darf. und: wie mache ich im Skript klar, daß der user gerlach wirklich der user gerlach ist, der auf /dev/tty11 schreiben darf. thx Ekkard
Hallo, Ekkard Gerlach:
Einspruch: wenn ich dem Skript den owner "egerl" gebe, an den niemals mails gerichtet sind und der keine .procmailrc hat, dann gibt whoami oder id aus owner auch egerl mit seiner ID 501 aus, siehe meine Antwortmail auf Bernd, die sich mit Deiner überschnitten hat.
Aha...dann scheint es tatsächlich so zu sein, daß procmail, als root gestartet, nicht auf den Empfänger runterschaltet, sondern auf den Scripteigentümer. Damit hätte ich jetzt nicht gerechnet. fetchmail ist da sehr viel strenger, der prüft sehr penibel auf Rechte und Lesbarkeit seiner fetchmailrc
ok. Jetzt sag mit noch, warum ich im Skript nicht auf /dev/tty11 schreiben darf, obwohl gerlach in der Gruppe tty ist und von einem xterm das darf.
und: wie mache ich im Skript klar, daß der user gerlach wirklich der user gerlach ist, der auf /dev/tty11 schreiben darf.
Öhm... Probier doch mal echo "Hallo" >> /dev/tty10 Gruß, Ratti
Moin, Ratti:
Öhm... Probier doch mal echo "Hallo" >> /dev/tty10
Ekkard Gerlach:
das ist doch gerade das, was auf einem xterm oder konsole geht, weil gerlach in der Gruppe tty ist. Es geht eben nicht vom Skript aus.
Schrei hier nicht so rum, ;-)))) Du hast ">" verwendet, ich hatte ">>" vorgeschlagen. Aber ich lese gerade, dass du inzwischen auf der Sonnenseite der Scriptprogrammierung angekommen bist, sprich: Es läuft. Glückwunsch. ;-) Gruß, Ratti
Hallo Bernd, * Bernd Brodesser schrieb:
unter welchen Rechten läuft ein von procmail gestartetes Skript? Okay, unter dem Namen des Owner des Skriptes,
Wie kommst Du darauf?
Weil whoami -> gerlach ausgibt, siehe unten.
Mach mal id, der gibt mehr aus.
das gibt den gleichen User aus! Siehe unten.
Kann ja sein, daß der Prozeß und die Datei die gleiche UID haben. Aber das rührt nicht daher, sondern ist mehr oder weniger Zufall.
Glaube ich nicht. WEnn ich den Skript-owner auf egerl statt gerlach setze, bekomme ich die enstsprechenden Ausgaben: owner = gerlach: ^^^^^^^^^^^^^^^ rex:~ # cat /tmp/pwd gerlach (Ausgabe von whoami) ----- uid=500(gerlach) gid=100(users) (Ausgabe von id) owner = egerl: ^^^^^^^^^^^^^ rex:~ # cat /tmp/pwd egerl ----- uid=501(egerl) gid=100(users) soviel Zufall gibt's nicht! Ich glaube, da kannst Du auch noch dazulernen, Bernd!
Natürlich nicht. Ein Skript beachtet nicht das SUID-Bit, und läuft daher *nicht* unter dem Namen des Besitzers, es sei den, derjenige, der es ausführt ist zufällig im ihm identisch.
offensichtlich läuft das Skript DOCH unter dem Namen des Skript-owners!
Das Skript läuft unter dem, der es ausführt. In diesem Falle also unter dem gleichen, wie derjenige, der auch procmail ausführt.
Und wer ist procmail ? Welcher user? Habe Suse 7.2, weiß Du es?
Nö, woher soll ich wissen, wer bei Dir procmail aufruft. Ich mache das per fetchmail.
Mit ist eingefallen, daß procmail sich beim Aufruf von "sendmail -q -v" vom root in Bewegung setzt. Also ruft wohl root procmail auf. Oder??? Also läuft procmail als user root! Widerspruch zu Ausgabe von ID und whoami. WER KANN HIER WEITERHELFEN ????
Kann natürlich auch ganz fieß da irgendetwas fest einprogrammiert sein, kann aber nur funktionieren, wenn es als root läuft. Da aber kein SUID gesetzt ist und Du es nicht als root aufrufst kann es auch
... es ist wohl DOCH root der Initiator. Wo bitte programmiert da Suse in ihrer Distri etwas ganz "fieß" ein?
das nicht sein. Wäre aber auch sehr ungewöhnlich, sowas macht eigentlich nur init.
(Die Frage mag dumm klingen, aber ich weiß es wirklich nicht! Irgendein Howto, man-Seite oder so parat ? Man sudo kenne ich und verstehe es halbwegs. Allerdings stehen da keine Zusammenhänge mit Skripten, die von ?? getartet wurden.)
So funktioniert sudo. Da muß ein sudo davor, wie sonst könnte sudo funktionieren?
Woher weiß sudo dann, daß er die Superuserrechte, die nur gerlach
Das Skript wird immer als denjenigen ausggeführt, der es gestartet hat. Genauer, die shell, die das Skript ausführt, hat den gleichen realen und effektiven UID wie der aufrufende Prozess.
Gut, wenn von root der Start von Procmail ausgeht, dann müßte das Skript, das von procmail aus aufgerufen wird, auch unter root-Rechten laufen. Das ist aber tatsächlich nicht so. ID und whoami nennen klar den Owner des Skriptes und nicht root.
aber die REchte des Owners hat es wohl nicht:
Doch.
warum gibt dann whoami -> gerlach aus? Wenn ich den Owner des Skriptes auf einen anderen user "Testuser" setze, dann ist whoami -> "Testuser". Deshalb habe ich darauf geschlossen. Habe mich allerdings auch schon gewundert, wie ein procmail Prozess einfach so die Rechte von gerlach oder Testuser ergreifen kann.
Das wäre der typische Fall, wenn das SUID-Bit des Skriptes gesetzt wäre, nur bei Skripten funktioniert das SUID-Bit nicht. Also auch wenn es gesetzt ist, nutzt es nichts. Vielleicht macht whoami ja Mist.
ID gibt den gleichen "Mist" aus.
procmail startet in /home/gerlach/.procmailrc
:0 H * Subject: test | /usr/local/bin/myskript
das Skript myskript: (-rwxr-xr-x 1 gerlach users 613 Feb 25 19:02 myskript)
Darf jeder ausführen, also auch procmail, egal unter welchem User.
#!/bin/sh /usr/bin/whoami > /tmp/pwd ^^^^^^^--- das gibt den Namen des owners des Skriptes aus.
/usr/bin/id >> /tmp/pwd
echo "Hallo" > /dev/tty10 sudo /usr/sbin/isdnctrl dial ippp0
Habe in mein Skript eine Schleife eingebaut, um das Skript lange mit sich selber zu beschäftigen: for j in `seq 1 20000`; do time=`/bin/date '+%H%M'` done .. und prompt bekommen ich über top den owner heraus: 3108 gerlach 9 0 1772 1772 892 S 3.1 0.6 0:00 sss_fetch Also tatsächlich gerlach. Wenn das Skript dem owner egerl bekommt, dann ist unter top "egerl" angezeigt! hier ahne ich mittlerweile auch warum ein "sudo" erforderlich ist und sonst nicht: ich habe bei isdnctrl schon seit Wochen das SUID gesetzt. Deshalb ist es von beliebigen user-Shells aus isdnctrl nutzbar. Da das Skript mit der ID des owner "gerlach" ausgeführt wird, aber im Skript nicht mit vollständigen Rechten von gerlach ausgeführt wird, muß sudo her um das irgendwie zu bekräftigen. Ohne sudo ist isdnctrl im Skript nicht startbar, auch wenn isdnctrl das SUID-Bit gesetzt hat. Und wenn isdnctrl dann mit sudo startbar ist, dann ist zusätzlich das SUID5 erforderlich, weil isdnctrl auf /dev/isdninfo zugreift. Dazu reicht sudo offenbar nicht aus (die Rechte gelten nur für den Befehl isdnctrl und sind keine Identität "root" wie das das SUID macht. ($:~ > ls /dev/isdninfo -l cr--r--r-- 1 root root 45, 255 Mai 12 2001 /dev/isdninfo) JEtzt würde mich noch interessieren, wie ich im Skript eine Ausgabe auf /dev/tty11 machen kann. User gerlach darf das von einem xterm aus, nicht aber im Skript, obwohl das unter seinem Namen läuft. Eigentlich interessiert mich allgemein, unter welchem User das von procmail gestartet Skript nu wirklich läuft. Diese try-and-error erinnert mich zu sehr an M$. Ich werde langsam sauer ...
Woher weiß sudo dann, daß er die Superuserrechte, die nur gerlach an isdnctrl hat, benutzen darf? Davon, daß gerlach der owner des Skriptes ist?
Nein, weil es so im /etc/sudoers eingetragen hast. Vielleicht hast Du auch ALL eingetragen Ja und der User darf dann alle Superuserbefehle mit einem sudo davor ausführen. Nein! getestet:
gerlach@rex:$ sudo /sbin/fdisk Sorry, user gerlach is not allowed to execute '/sbin/fdisk' as root on rex. Erst wenn in sudoers steht: gerlach ALL=(ALL) NOPASSWD: /sbin/fdisk dann darf user gerlach fdisk benutzen. ALL ist *KEIN* Freibrief für alle root-Kommandos.
Ein NOPASSWD wirst Du ihm auch mitgegeben haben, sonst hätte er ja nach dem Passwort gefragt. Ja.
Hat nichts damit zu tun, wem die Datei gehört. Wem eine Datei gehört ist irrelevant, außer das SUID-Bit ist gesetzt und für wem welche Rechte zählen, aber wenn so wie so alle ausführen dürfen, ist es für die Ausführung irrelevant. Es wird immer mit der UID dessen ausgeführt, der es aufruft. Besser gesagt des Prozesses, der aufruft.
Diese Aussage stimmt bisher nicht. Vielleicht auch weil *doch* root der Initiator ist. Da wüßte ich gerne wie das funktioniert, dafür würde ich gerne mal ein Tutorial, HowTo, .. lesen. Aber scheinbar gibt es so etwas nicht. thx Ekkard
Hi Ekkard, On Thu, Feb 28, 2002 at 02:12:50AM +0100, Ekkard Gerlach wrote:
Mach mal id, der gibt mehr aus.
das gibt den gleichen User aus! Siehe unten.
jede Menge richtiges und Zeug was ich nicht nachprüfen mag gelöscht aaaber es kommt immer drauf an wie genau der procmail aufgerufen wird, beim postfix wird er idr. so aufgerufen: procmail unix - n n - - pipe flags=R user=cyrus argv=/usr/bin/procmail -t -m USER=${user} EXT=${extension} /etc/procmailrc fällt dir da was auf? hoffe zu völliger Verwirrung beigetragen zu haben :-)) -- MfG. Falk
Hi Ekkard,
On Thu, Feb 28, 2002 at 02:12:50AM +0100, Ekkard Gerlach wrote:
Mach mal id, der gibt mehr aus.
das gibt den gleichen User aus! Siehe unten.
jede Menge richtiges und Zeug was ich nicht nachprüfen mag gelöscht
aaaber es kommt immer drauf an wie genau der procmail aufgerufen wird, beim postfix wird er idr. so aufgerufen:
procmail unix - n n - - pipe flags=R user=cyrus argv=/usr/bin/procmail -t -m USER=${user} EXT=${extension} /etc/procmailrc
fällt dir da was auf?
so ein ARt setuid,oder? - ok. Jetzt sag mir noch warum ich als user Gerlach in einem Skript von procmail gestartet (id gibt gerlach aus, sie andere Mails von mir in diesem thread) ein echo "Hallo" > /dev/tty11 nicht absetzten darf. Von einem xtern oder Konsole geht's nämlich. Gruss Ekkard
* Ekkard Gerlach schrieb am 28.Feb.2002:
* Bernd Brodesser schrieb:
owner = gerlach: ^^^^^^^^^^^^^^^ rex:~ # cat /tmp/pwd gerlach (Ausgabe von whoami) ----- uid=500(gerlach) gid=100(users) (Ausgabe von id)
Mehr gibt id nicht aus? Staun.
Ich glaube, da kannst Du auch noch dazulernen, Bernd!
Nun ja, ich habe dazugelernt, daß procmail den Owner verändert. Ein Skript kann das nicht. Das geht letztendlich nur mit dem Systemaufruf setuid oder mit dem SUID-Bit, letzteres aber nicht bei einem Skript. Folglich macht procmail ein setuid.
Natürlich nicht. Ein Skript beachtet nicht das SUID-Bit, und läuft daher *nicht* unter dem Namen des Besitzers, es sei den, derjenige, der es ausführt ist zufällig im ihm identisch.
offensichtlich läuft das Skript DOCH unter dem Namen des Skript-owners!
Das macht aber nicht der Kernel, sondern procmail
Mit ist eingefallen, daß procmail sich beim Aufruf von "sendmail -q -v" vom root in Bewegung setzt. Also ruft wohl root procmail auf. Oder???
Muß schon root sein, sonst führt setuid nicht zum Erfolg.
Also läuft procmail als user root! Widerspruch zu Ausgabe von ID und whoami. WER KANN HIER WEITERHELFEN ????
Wo machst Du whoami? Offensichtlich führt procmail Unterprozesse als ein anderer User aus. Das kann es aber nur, wenn es root ist. Genauer, es macht ein fork, und wenn beim fork eine 0 zurückgegeben wird, es sich also um das Kind handelt, dann wird zuerst ein setuid und ähnliche ausgeführt, dann erst ein exec.. Mach doch mal ein ps. Wer wird dann als Owner ausgegeben?
Kann natürlich auch ganz fieß da irgendetwas fest einprogrammiert sein, kann aber nur funktionieren, wenn es als root läuft. Da aber kein SUID gesetzt ist und Du es nicht als root aufrufst kann es auch
... es ist wohl DOCH root der Initiator. Wo bitte programmiert da Suse in ihrer Distri etwas ganz "fieß" ein?
Was hat SuSE damit zu tun? Die habe es nur auf der CD gepackt. Wie habe ich oben beschrieben. Das haben die Programmierer von procmail gemacht.
das nicht sein. Wäre aber auch sehr ungewöhnlich, sowas macht eigentlich nur init.
Offensichtlich doch nicht.
Gut, wenn von root der Start von Procmail ausgeht, dann müßte das Skript, das von procmail aus aufgerufen wird, auch unter root-Rechten laufen. Das ist aber tatsächlich nicht so. ID und whoami nennen klar den Owner des Skriptes und nicht root.
procmail setzt es halt anders.
Habe in mein Skript eine Schleife eingebaut, um das Skript lange mit sich selber zu beschäftigen:
for j in `seq 1 20000`; do time=`/bin/date '+%H%M'` done
warum machst Du nicht einfach ein sleep?
.. und prompt bekommen ich über top den owner heraus:
3108 gerlach 9 0 1772 1772 892 S 3.1 0.6 0:00 sss_fetch
und was sagt top zu procmail? Wenn was anderes als root, würde es mir stark wundern.
Eigentlich interessiert mich allgemein, unter welchem User das von procmail gestartet Skript nu wirklich läuft. Diese try-and-error erinnert mich zu sehr an M$. Ich werde langsam sauer ...
Schau Dir die Quellen von procmail an.
Woher weiß sudo dann, daß er die Superuserrechte, die nur gerlach an isdnctrl hat, benutzen darf? Davon, daß gerlach der owner des Skriptes ist?
Nein, weil es so im /etc/sudoers eingetragen hast. Vielleicht hast Du auch ALL eingetragen Ja und der User darf dann alle Superuserbefehle mit einem sudo davor ausführen. Nein! getestet:
gerlach@rex:$ sudo /sbin/fdisk Sorry, user gerlach is not allowed to execute '/sbin/fdisk' as root on rex.
Erst wenn in sudoers steht: gerlach ALL=(ALL) NOPASSWD: /sbin/fdisk dann darf user gerlach fdisk benutzen. ALL ist *KEIN* Freibrief für alle root-Kommandos.
ALL hat an verschiedenen Stellen verschiedene Bedeutungen. Bei Dir heist das erste ALL, daß der User gerlach zu allen User werden darf. Du dürftest auch sudo -u egerl /sbin/fdisk ausführen. Nun gut, mit fdisk geht dies natürlich nicht. Das ALL in Klammern sagt nur, daß Du es von jeder Maschiene aus machen darfst. Wenn anstelle von /sbin/fdisk ALL stehen würde, dann dürftest Du jeden Befehl ausführen. Ich hoffe, das war jetzt richtig. sudo benutze ich nicht mehr.
Hat nichts damit zu tun, wem die Datei gehört. Wem eine Datei gehört ist irrelevant, außer das SUID-Bit ist gesetzt und für wem welche Rechte zählen, aber wenn so wie so alle ausführen dürfen, ist es für die Ausführung irrelevant. Es wird immer mit der UID dessen ausgeführt, der es aufruft. Besser gesagt des Prozesses, der aufruft.
Diese Aussage stimmt bisher nicht. Vielleicht auch weil *doch* root der Initiator ist. Da wüßte ich gerne wie das funktioniert, dafür würde ich gerne mal ein Tutorial, HowTo, .. lesen. Aber scheinbar gibt es so etwas nicht.
man 2 setuid Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
* Bernd Brodesser schrieb:
* Ekkard Gerlach schrieb am 28.Feb.2002:
* Bernd Brodesser schrieb:
owner = gerlach: ^^^^^^^^^^^^^^^ rex:~ # cat /tmp/pwd gerlach (Ausgabe von whoami) ----- uid=500(gerlach) gid=100(users) (Ausgabe von id)
Mehr gibt id nicht aus? Staun.
ohhh... gar nicht bemerkt daß ein /usr/bin/id >> /tmp/pwd im Skript weit weniger ausgibt als ein "id" an der Konsole. Ein id am xterm/ Konsole: uid=500(gerlach) gid=100(users) Gruppen=100(users),5(tty),14(uucp),16(dialout)
Ich glaube, da kannst Du auch noch dazulernen, Bernd!
Nun ja, ich habe dazugelernt, daß procmail den Owner verändert. Ein Skript kann das nicht. Das geht letztendlich nur mit dem Systemaufruf setuid oder mit dem SUID-Bit, letzteres aber nicht bei einem Skript. Folglich macht procmail ein setuid.
Natürlich nicht. Ein Skript beachtet nicht das SUID-Bit, und läuft daher *nicht* unter dem Namen des Besitzers, es sei den, derjenige, der es ausführt ist zufällig im ihm identisch.
offensichtlich läuft das Skript DOCH unter dem Namen des Skript-owners!
Das macht aber nicht der Kernel, sondern procmail
... ohhh ... diese Unterscheidung habe ich noch nie gemacht ..
Mit ist eingefallen, daß procmail sich beim Aufruf von "sendmail -q -v" vom root in Bewegung setzt. Also ruft wohl root procmail auf. Oder???
Muß schon root sein, sonst führt setuid nicht zum Erfolg.
Also läuft procmail als user root! Widerspruch zu Ausgabe von ID und whoami. WER KANN HIER WEITERHELFEN ????
Wo machst Du whoami? Offensichtlich führt procmail Unterprozesse als
direkt vor "id", siehe unten
ein anderer User aus. Das kann es aber nur, wenn es root ist.
mein Skript, das von /home/gerlach/.procmailrc aus gestartet wird : #!/bin/sh /usr/bin/whoami > /tmp/pwd echo "-----" >> /tmp/pwd /usr/bin/id >> /tmp/pwd # i=0 # for j in `seq 1 20000`; do # time=`/bin/date '+%H%M'` #done echo "Hallo" > /dev/tty10 echo "Hallo" > /dev/tty11 exit 0 Das auskommentierte ist eine lange Warteschleife, die viel Zeit läßt, unter top den user des Skriptes zu erkennen.
Genauer, es macht ein fork, und wenn beim fork eine 0 zurückgegeben wird, es sich also um das Kind handelt, dann wird zuerst ein setuid und ähnliche ausgeführt, dann erst ein exec..
Mach doch mal ein ps. Wer wird dann als Owner ausgegeben?
ebenso gerlach oder egerl, wie oben unter nutzung der for-Warteschleife unter top ersichtlich.
Kann natürlich auch ganz fieß da irgendetwas fest einprogrammiert sein, kann aber nur funktionieren, wenn es als root läuft. Da aber kein SUID gesetzt ist und Du es nicht als root aufrufst kann es auch
... es ist wohl DOCH root der Initiator. Wo bitte programmiert da Suse in ihrer Distri etwas ganz "fieß" ein?
Was hat SuSE damit zu tun? Die habe es nur auf der CD gepackt. Wie habe ich oben beschrieben. Das haben die Programmierer von procmail gemacht.
.. ach so tiefgründig ist das vielleicht verankert ...
das nicht sein. Wäre aber auch sehr ungewöhnlich, sowas macht eigentlich nur init.
Offensichtlich doch nicht.
Gut, wenn von root der Start von Procmail ausgeht, dann müßte das Skript, das von procmail aus aufgerufen wird, auch unter root-Rechten laufen. Das ist aber tatsächlich nicht so. ID und whoami nennen klar den Owner des Skriptes und nicht root.
procmail setzt es halt anders.
Habe in mein Skript eine Schleife eingebaut, um das Skript lange mit sich selber zu beschäftigen:
for j in `seq 1 20000`; do time=`/bin/date '+%H%M'` done
warum machst Du nicht einfach ein sleep?
weile es dann nicht mehr unter top an oberer Stelle erscheint.
.. und prompt bekommen ich über top den owner heraus:
3108 gerlach 9 0 1772 1772 892 S 3.1 0.6 0:00 sss_fetch
und was sagt top zu procmail? Wenn was anderes als root, würde es mir stark wundern.
das "erwische" ich nicht. Es ist einfach zu schnell beendet. Gibt es da ein tool, das alle Prozesse aufzeichnet?
Eigentlich interessiert mich allgemein, unter welchem User das von procmail gestartet Skript nu wirklich läuft. Diese try-and-error erinnert mich zu sehr an M$. Ich werde langsam sauer ...
Schau Dir die Quellen von procmail an.
Also gut, procmail ist ein Sonderfall. Jetzt will ich ich aber immer noch in dem procmail-Skript eine Ausgabe auf /dev/tty11 machen und darf es nicht obwohl das Skript uid=500 (gerlach) und gerlach von einem xterm das darf. Eine Lösung? thx Ekkard
* Ekkard Gerlach schrieb am 01.Mär.2002:
* Bernd Brodesser schrieb:
* Ekkard Gerlach schrieb am 28.Feb.2002:
owner = gerlach: ^^^^^^^^^^^^^^^ rex:~ # cat /tmp/pwd gerlach (Ausgabe von whoami) ----- uid=500(gerlach) gid=100(users) (Ausgabe von id)
Mehr gibt id nicht aus? Staun.
ohhh... gar nicht bemerkt daß ein /usr/bin/id >> /tmp/pwd im Skript weit weniger ausgibt als ein "id" an der Konsole. Ein id am xterm/ Konsole: uid=500(gerlach) gid=100(users) Gruppen=100(users),5(tty),14(uucp),16(dialout)
Ja, procmail setzt nicht nur den User, sondern auch die Gruppe. Daher gibt es nichts anderes.
Also gut, procmail ist ein Sonderfall.
procmail verändert den Besitzer. Dies ist mit einem Systemaufruf möglich, wenn der reale oder efektive User root ist. Andernfalls könte z.B login nicht zu der shell des Users mutieren.
Jetzt will ich ich aber immer noch in dem procmail-Skript eine Ausgabe auf /dev/tty11 machen und darf es nicht obwohl das Skript uid=500 (gerlach) und gerlach von einem xterm das darf.
Nein, Du darfst es, weil Du auch in der Gruppe tty bist. Geb das skript doch mal die Gruppe tty, und schau mal, was dann passiert.
Eine Lösung?
Hoffentlich. Bernd -- Probleme mit dem Drucker? Schon die Druckercheckliste beachtet? http://localhost/doc/sdb/de/html/drucker-howto.html | Auch lesenswert: Oder schon das Drucker-HOWTO gelesen? | man lpr file://usr/shar/doc/howto/de/DE-Drucker-HOWTO.txt.gz | Zufallssignatur 3
Hallo Bernd,
Nein, Du darfst es, weil Du auch in der Gruppe tty bist. Geb das skript doch mal die Gruppe tty, und schau mal, was dann passiert.
Eine Lösung?
Jaaaa! Suuuuper! Endlich. Danke, Bernd! Habe mir mal alles in einem micro-Howto zusammengefaßt: Start eines Skriptes von .procmailrc aus ========================================== Ziel: in /home/<user>/.procmailrc soll bei bestimmten Mails ein Skript automatisch gestartet werden, das u.a. auch root-Befehle ausführt. Schwierigkeit: REchtevergabe Analyse des Ablaufes: * sendmail -q als root ausgeführt startet auch procmail. procmail hat also root-Rechte. * procmail von Suse 7.2 ist offenbar so programmiert, daß es das Skript unter dem user = owner des Skriptes und group = group des Skriptes startet. Das bedeutet: das Skript hat die Rechte des User und die Rechte der Gruppe des Skriptes. Das Skript hat NICHT die Rechte der Gruppe oder Gruppen, in der der User sonst zusätzlich ist. Durch Ausgabe von /usr/bin/id in dem Skript ist das zu verdeutlichen. * Superuser-Befehle können in dem Skript auf zwei Weise ausgeführt werden: 1. mit SUID-Flag: Dabei muß allerdings die Gruppe des Skriptes mit der Gruppe des superuser-Befehles übereinstimmen (voraus- gesetzt der owner des superuser-Befehls soll root bleiben und der owner des Skriptes eben nicht) 2. mit sudo : in sudoers wird der superuser-Befehl zur Ausführung freigegeben. Im Skript muß dann "sudo" vor dem superuser- Befehl stehen. Nachteil: die superuser-Rechte werden ohne SUID nicht an andere Befehle, Programme und devices weitergegeben Wer die Gruppen nicht anpassen kann, muß in diesem Fall zusätzlich SUID setzen. Dann ist die Anpassung der Gruppen *NICHT* mehr notwendig. Beispiel: isdncrtl braucht zur Ausführung /dev/isdninfo. isdninfo ist ein root - root -Device. Der Eintrag von isdnctrl in sudoers reicht nicht, um den Befehl auszuführen. Es muß entweder: * die Gruppe von isdnctrl an die des Skriptes angepaßt werden oder * isdnctrl zusätzlich zur Freigabe in sudoers das SUID-Flag erhalten. Ekkard
participants (4)
-
B.Brodesser＠t-online.de -
Ekkard Gerlach -
Falk Sauer -
Ratti