Wie legst Du denn die Datei an? Wenn Du z.B system verwendest, funktioniert es, aus den gleichen Gründen wie bei der shell direkt, nicht. Siehe man system und da unter BUGS.

Das Programm selbst wird ueber den Webserver mit system() aufgerufen. Das Programm ist ziehmlich komplex, und benoetigt auch fuer andere Aktionen root-Rechte, zB: das Oeffnen der Geraetedateien /dev/cub0 .. /dev/cub7 Es wird in diesem Programm auch ein Perl-script aufgerufen (aus Sicherheitsgruenden wird die Pruefsumme des Scrips ermittelt). Alles hatte wunderbar mit sudo geklappt. Nur wenn ich die sudoers-Datei von Rechner A auf Rechner B kopiere, dann weigert sich sudo diese Datei zu akzeptieren (ich hab keine Ahnung warum das so ist). Also dachte ich mir, ich kann die sudo-Funktionalitaet mit Vergabe von suid-Rechten ersetzen. Das ist aber anscheinend nicht der Fall. Ist es nicht doch Moeglich die sudoers -Datei irgendwie auf einen anderen Rechner zu uebernehmen, und "sudo" dazu zu bewegen das zu akzeptieren? Erich -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

* Erich Lindner schrieb am 28.Nov.2002:

Bitte Attributzeile stehen lassen, in dem der Vorredner, in diesem Fall ich, erwähnt wird.

sorry, ich lass den oberen Bereich mal unveraendert, ich weiss nicht genau, ob ueber den gmx-Webmailer das korrekt uebermittelt wird, ich benutze normalerweise den pop/smtp-Zugang von gmx.

...

...

Wie legst Du denn die Datei an? Wenn Du z.B system verwendest, funktioniert es, aus den gleichen Gründen wie bei der shell direkt,

^^^^^^^^^^^^^^

...

...

nicht. Siehe man system und da unter BUGS.

heisst das, dass der Programmaufruf als user "wwwrun" von der Kommandozeile das gleiche Problem verursacht, und wg. mangels Rechte die Ausfuehrung abgebrochen wird. also zuerst "su" root-Passwort und dann "su wwwrun" und dann "/sbin/boxprog start" diese Variante hatte ich auch probiert, allerdings ohne Erfolg Erich -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

On Don, 28 Nov 2002 at 19:39 (+0100), Bernd Brodesser wrote:

* Erich Lindner schrieb am 28.Nov.2002:

...

...

...

...

Wie legst Du denn die Datei an? Wenn Du z.B system verwendest, funktioniert es, aus den gleichen Gründen wie bei der shell direkt,

^^^^^^^^^^^^^^

...

...

...

nicht. Siehe man system und da unter BUGS.

heisst das, dass der Programmaufruf als user "wwwrun" von der Kommandozeile das gleiche Problem verursacht, und wg. mangels Rechte die Ausfuehrung abgebrochen wird.

Du mußt Dein C-Programm umstricken. So wie Du es gemacht hast, also mit der Funktion system() funktioniert es nicht. Die Funktion system() nimmt das SUID-Bit weg. Genauso, wie es die bash tut, und mit genau der gleichen Begründung

Nein, das stimmt nicht. Die Ursache liegt im fehlenden setuid(0) Aufruf innerhalb des Programms. Siehe unten. [...]

/sbin/boxprog muß anders programmiert werden, ohne system() stattdessen mit fopen(), fclose() und fprintf() und gegebenenfalls auch mit execve() und fork()

Auch hier wieder: Nein. Der Weg über fork() und execve() ist sicher der sauberere, aber es funktioniert auch so - man muss eben nur die effektive UserID auch tatsächlich wechseln: jan@k500:~/tmp> cat sid.c #include #include #include #include #include int main (int argc, char **argv) { if (system ("echo $$ >/var/run/sid") != 0) printf ("vor setuid: Fehler bei schreiben der PID\n"); else printf ("vor setuid(): OK!\n"); if (setuid (0) == -1) { printf ("Fehler bei setuid() (%d): %s\n", errno, strerror (errno)); return (0); } if (system ("echo $$ >/var/run/sid") != 0) printf ("nach setuid: Fehler bei schreiben der PID\n"); else printf ("nach setuid(): OK!\n"); return (0); } jan@k500:~/tmp> make sid cc sid.c -o sid jan@k500:~/tmp> ll sid -rwxr-xr-x 1 jan users 14270 Nov 28 22:45 sid jan@k500:~/tmp> ./sid sh: /var/run/sid: Keine Berechtigung vor setuid: Fehler bei schreiben der PID Fehler bei setuid() (1): Operation not permitted jan@k500:~/tmp> su Password: k500:/home/jan/tmp # ./sid vor setuid(): OK! nach setuid(): OK! k500:/home/jan/tmp # chown root:root sid k500:/home/jan/tmp # chmod 04755 sid k500:/home/jan/tmp # exit jan@k500:~/tmp> ./sid sh: /var/run/sid: Keine Berechtigung vor setuid: Fehler bei schreiben der PID nach setuid(): OK! jan@k500:~/tmp> cat /var/run/sid 1756 Jan

Jan Trippler wrote:

On Don, 28 Nov 2002 at 19:39 (+0100), Bernd Brodesser wrote:

...

Du mußt Dein C-Programm umstricken. So wie Du es gemacht hast, also mit der Funktion system() funktioniert es nicht. Die Funktion system() nimmt das SUID-Bit weg. Genauso, wie es die bash tut, und mit genau der gleichen Begründung

Ich hab mich eventuell nicht korrekt ausgedrueckt. Das Programm selbst macht keinen "system()" -Aufruf sondern dieses wird ueber einen System() -Aufruf gestartet ( durch ein CGI-Script ). Allerdings wird in diesem Programm ein anderes Programm mit popen() kontaktiert ,und mit Kommandos gefuettert, und dieses ueber eine Pipe verbundene Programm erzeugt dann den Fehler.

Nein, das stimmt nicht. Die Ursache liegt im fehlenden setuid(0) Aufruf innerhalb des Programms. Siehe unten.

if (setuid (0) == -1) { printf ("Fehler bei setuid() (%d): %s\n", errno, strerror (errno)); return (0); }

das wars :-) ich hab dies im Programm aufgenommen und neu uebersetzt, und es funktioniert tatsaechlich. danke fuer eure Hilfe Erich

Hallo Jan, * Jan Trippler schrieb am 28.Nov.2002:

Das Set-UID-Bit der Programmdatei verleiht dem Programm nur das _Recht_, die effektive UID zu der des Eigentümers der Datei zu ändern und damit mit seinen Rechten zu laufen, das Programm muss es aber explizit tun (dazu hatte ich vor ein paar Wochen schon mal ausführlich was geschrieben im Thread *cdbakeoven*).

Du musst also, bevor Du Aktionen ausführst, die Root-Rechte erfordern, erst die ID wechseln mit dem Call setuid(0) - dann klappts auch mit dem Nachbarn. Siehe dazu: man 2 setuid

Nein. Das kann gar nicht sein. Es wird das effektive Recht überrüft, nicht das reale. Wenn das effektive Recht stimmt, dann darf man. Ich habe es doch auch mit fopen versucht, und es funktioniert. --------------------------------------------------------------- #include #include extern int errno; main() { FILE *datei; if ((datei = fopen ("suid.out", "w")) == NULL) { fprintf (stderr, "%d Mist\n", errno); exit (1); } fprintf(datei,"hallo\n"); fclose (datei); } --------------------------------------------------------------- Dieses Progrämmchen übersetzt. Den Owner root.root geben und das SUID-Bit setzen. Anschließend ausführen. Falls die Datei suid.out noch nicht existiert, wird sie angelegt und hat die Rechte root.root. 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

* Jan Trippler schrieb am 28.Nov.2002:

Hmm, jetzt müsste man IMHO mal tiefer in die System-Calls einsteigen. Dein fopen() klappt ohne setuid() (auch in /var/run), der system() klappt nur mit setuid() - siehe meine andere Mail. Andere Funktionen (wie z. B. ein stat("/etc/shadow", R_OK) - das hatte ich vor ein paar Wochen mal in einem anderen Thread benutzt) klappen auch nur _mit_ setuid().

man setuid() sagt auch aus, dass hier die _effektive_ User-ID gesetzt wird.

Ich habe mir das ganze mal angetan, und mal Manpages gelesen und ein wenig rumprobiert. Schon alles etwas gaga. Insgesamt gibt es vier verschiedene UIDs. GIDs habe ich nicht untersucht, wird wohl so ähnlich sein, höchstens noch etwas komplizierter, weil es neben der primäre Gruppe noch andere Gruppen geben kann. Die /etc/passwd wird bei allen Systemaufrufen nicht berücksichtigt. Es ist vollkommen ohne Belang, ob es den jeweiligen UID in der /etc/passwd gibt, oder nicht. Die vier UIDs sind: Der reale UID kurz ruid. Der effektive UID, kurz euid. Der abgesicherte UID, kurz suid. Hat direkt nichts mit dem SUID-Bit zu tun, wird aber leider allgemein so bezeichnet, für savedUID. Ich habe es so belassen. Den Namen sollte man nicht allzuviel Bedeutung bemessen. Der fsuid, was immer das heißen mag. Der Prozeß hat Superuserprivilegien, sobald der euid gleich 0 ist. Die Rechte einer Datei werden anhand des fsuid ausgewertet. Hier nützt die 0 im euid nichts, hier zählt nur der fsuid. Wenn ein Prozeß gestartet wird, dann werden alle vier UIDs beibehalten. Wenn das SUID-Bit gesetzt ist, so wird nur der ruid beibehlaten. euid, suid und fsuid bekommen den UID der Datei, die ausgeführt wird. Wenn diese Datei root gehört, so werden sie somit auf 0 gesetzt. Insbesondere auch der euid. Zur Veränderung der UIDs gibt es folgende Systemaufrufe: setuid seteuid setresuid setfsuid setreuid Zur Anzeige die folgende: getuid geteuid getresuid getuid und geteuid haben keine Argumente und geben den ruid, bzw. den euid aus. getresuid bekommt als Argument drei Zeiger, in dem ersten wird der ruid, im zweiten der euid und im dritten der suid abgelegt. Besonders schön ist es, daß es anscheinend keine Funktion gibt, die den sfuid ausgibt. Von den ganzen set-Funktionen verhält sich imho setresuid am vernünftigsten. setresuid bekommt drei Argumente mit, die neuen ruid, euid und suid. Wenn die Funktion erfolgreich war, wird eine 0 zurückgegeben, sonst eine -1 und errno wird gesetzt. Wenn der bisherige euid 0 war, so darf alles mögliche gesetzt werden. Ansonten darf alles gesetzt werden, was bisher in ruid, euid und suid standen. Es darf alles gleich gesetzt werden, es darf auch munter permutiert werden. Es kann somit sein, daß der neue ruid der alte euid ist, der neue euid der alte suid und der neue suid der alte ruid. Oder auch umgekehrt. Wenn in einem der UIDs eine -1 gesetzt wird, dann wird der bisherige UID beibehalten. Gilt so für alle drei UIDs. Wird der euid verändert, so wird wie sonst auch immer der fsuid mit verändert. Bemerkenswert ist, wenn der alte euid ungleich 0 ist, aber etwa der alte ruid und/oder der alte suid gleich 0, so dürfen die UIDs trotzdem nicht beliebig gesetzt werden, sondern nur aus der Auswahl von ruid, euid und suid. Da da aber eine 0 dabei war, darf der euid auf 0 gesetzt werden, und in einem nächsten Schritt darf dann beliebig gesetzt werden. Etwas merkwürdiger verhält sich die Funktion setuid. Falls der euid ungleich 0 ist, wird der euid verändert, und wie immer, damit auch der fsuid. Dies darf aber nur der bisherige ruid oder der bisherige suid sein. Ansonsten gibt es einen Fehler. Dies gilt merkwürdigerweise auch, wenn der neue euid gleich dem alten ist, aber ungleich von ruid und suid. Ganz anders verhält sich setuid, wenn der alte euid gleich 0 ist. Dann werden alle vier UIDs auf dem Argument von setuid gesetzt, das jetzt beliebig sein kann. Ebenfalls merkwürdig verhält sich setreuid. setreuid hat zwei Argumente. Das erste Argument ist der neue ruid, und das zweite der neue euid. Wenn der alte euid gleich 0 ist, darf auch hier wieder mal beliebig gesetzt werden. Ist der euid aber ungleich 0, so darf der ruid nur auf dem alten ruid oder dem alten euid gesetzt werden, der euid darf auf dem alten ruid oder dem alten euid oder dem alten suid gesetzt werden. Der ruid darf aber nicht auf dem alten suid gesetzt werden, wenn er nicht zufälligerweise gleich dem alten ruid oder euid ist, oder der alte euid gleich 0. Auch hier wird der fsuid auf dem neuen euid gesetzt. Als wenn das nicht schon alles merkwürdig genug wäre, noch merkwürdiger ist das Verhalten vom suid. Meist wird der suid auch auf den Wert von euid gesetzt. Dies ist nicht der Fall, wenn der ruid beibehalten wird, und der euid entweder ebenfalls beibehalten wird (dann macht die Funktion aber rein gar nichts) oder aber wenn der euid auf dem alten ruid gesetzt wird. Dann bleibt der alte suid erhalten, ansonsten wird der suid auf dem neuen euid gesetzt. Dabei bleibt der ruid und auch der euid beibehalten wenn im Argument eine -1 steht. Wird der gleiche Wert gesetzt, auf dem der jeweilige UID sowieso schon steht, so gilt das nicht als beibehalten und suid wird trotzdem auf dem neuen euid gesetzt. *heul* seteuid (arg) soll laut manpage nichts anderes sein als setreuid (-1, arg) Habe ich jetzt nicht überprüft. Daraus ergibt sich, daß der ruid beibehalten wird, der suid dann beibehalten wird, wenn der euid auf dem alten ruid gesetzt wird, ansonsten aber ebenfalls auf dem neuen euid gesetzt wird. Der fsuid wird immer verändert, wenn auch der euid verändert wird. Die einzige Chance, daß da mal was anderes steht ist die Funktion setfsuid. Diese Funktion hat als einziges Argument den Wert des neuen fsuid und gibt als Rückgabewert den alten fsuid zurück. Und zwar immer, auch im Fehlerfalle. Alle anderen Funktionen geben in diesem Fall eine -1 zurück. Auch wird im Fehlerfall errno nicht gesetzt. Mit anderen Worten: Es läßt sich nicht feststellen, ob ein Fehler aufgetreten ist, oder nicht. *schrei* Wenn der euid 0 ist, so kann auch hier jeder Wert genommen werden. Ansonsten ruid, euid oder suid. Ich habe nicht alles überprüft, aber doch das meiste. Und irgendwie ist mir jetzt schlecht. Weiß auch nicht, was das alles soll. Wichtig ist der euid und der fsuid. Der ist aber sowieso immer der gleiche wie der euid, solange setfsuid nicht angefaßt wird. 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