Hi Christian Kruse

Ich würde keinem CGI-Skript andere Rechte geben, weil es in meinen Augen ein zu hohes Sicherheitsrisiko darstellt. Du würdest es damit jedem der dein Script cracken kann ermöglichen, sicherheitsrelewante Dinge zu tun. Und dein Script kann gar keine sichere Passwortabfrage machen, weil jeder den Quelltext einsehen kann. Außerdem geht dein Vorhaben gegen jegliche Modularisierung.

Ich würde es so machen:

Du schreibst ein Programm welches die Gewünschten Funktionen steuern b.z.w ausführen kann. Dieses Programm läuft dann als Dämon unter dem benötigtem User im Hintergrund und erwartet von dem zweitem Programm, dem CGI-Script, Eingaben.

Das CGI-Script stellt die Schnittstelle zwischen der eigentlichen Serveranwendung und dem Browser auf der Clientseite dar.
Es empfängt also Eingaben aus Formularen und leitet diese lediglich an den Dämon weiter. Umgekehrt stellt es die Ausgaben des Dämon HTML-typisch dar.

Die Vorteile:

• modulares Prinzip - du willst das Ganze übers Handy steuern, also schreibst du ein WAP-CGI und änderst nicht alles
• sicher - du (und der Cracker) geben das Passwort in das Formular ein und das CGI löst es nicht auf, sondern leidet es nur an den Dämon weiter, welcher es dann auflöst, und entsprächend ja oder nein sagt
• du kannst den Dämon in irgendeiner Programiersprache schreiben, die gerade am besten passt

Ja und wie das im Detail funzt musst du dir halt aneignen, oder weißt es schon.

Das wichtigste ist: sich dreimal das Konzept zu überlegen. Dabei ist Modularität, Erweiterbarkeit und Flexsibilität sehr wichtig.

Also denk mal drüber nach und mach es dann so wie Du willst...

ALEX

Auch das SUID-Bit für PERL möchte ich nicht setzen, da es keine Sicherheitslücke wäre, sondern eher ein Sicherheits-Scheunentor :-)

Wenn man nicht weiß, was man tut, dann ja.

Ansonsten ist sgid eine Alternative, eine andere sinnvolle Lösung gibt es meines Erachtens nach nicht.

cu,
Peter

Hallo!

Eine Pipe (open(SU,'>su '); print SU "user";) zu benutzen, schließt sich aus, da man leider die Passwort-Abfrage nicht auffangen kann (es wird eine Passwort-Eingabe per Tastatur erwartet).

Ich kann das Passwort ohne Probleme hineinpipen! Vielleicht liegt das ja an der Version von su.
Mich würde interessieren, ob es mit meiner Version bei euch auch funktioniert. Ihr könnt sie unter http://www.myhp.ch/download/su downloaden.

Gruss
Andreas

CGI-Scripts in PERL geschrieben werden ja unter Linux mit dem User "wwwrun" ausgeführt, der jedoch nur minimale Zugriffsrechte hat.

"Linux" ist kein Webserver, und in dem konkreten Webserver wird man das einstellen können.
(Wenn es Apache ist, ganz bestimmt.)

Meine Frage wäre, ob es eine Möglichkeit gibt, per PERL-CGI-Script den User zu wechseln, etwa um eine Webbasierte Oberfläche zur Verwaltung von Linux-Proxies zu erstellen (Anwahl, Apache-Konfigurationserweiterungen, usw).

Wenn Du die Benutzerkennung nicht für den gesamten, bereits existierenden Webserver verändern willst oder darfst, dann überlege mal, ob Deine Sonderanforderung die Installation eines eigenen Webservers rechtfertigt.
Du kannst auf demselben Server-Rechner beliebig viele Webserver laufen lassen, wenn diese über verschiedene TCP/IP-Ports angesprochen werden - diesen kann man bei Apache in der Konfiguration ändern.
(So mache ich das, wenn ich auf eine neue Apache-Version umsteige: Ich lasse beide Versionen auf demselben Dokumentbaum parallel laufen und ändere nach der Testphase nur noch die Portnummer.)
Vielleicht reicht für Deinen Fall auch schon ein separater virtueller Host?

Auch das SUID-Bit für PERL möchte ich nicht setzen, da es keine Sicherheitslücke wäre, sondern eher ein Sicherheits-Scheunentor :-)

In der Tat.