Moin, Ratti:
Falsch ist, daß perl sich weigert einen Befehl auszuführen, für den es eigentlich keine Restriktion gibt, weil er noch eigene obendrauf setzt.
Andre Heine:
Falsch ist das mit sicherheit nicht! Eher ein Feature.
Whatever...
Will sagen: Wenn su httpd whoami
funktioniert, dann hat #!/usr/bin/perl `whoami`
Wenn Du etwas von der Konsole ausführst ist das nicht so, als wenn CGI etwas ausführen.
Wenn ich es in `` setze, dann sollte es aber eigentlich genau das sein.
Die kennen normalerweise nur Ihr htdocs, das soll sein. Oder sehe ich das falsch?
Ich glaube - ja, siehst du falsch. ;-) Du kannst normalerweise völlig problemlos in einem CGI `/usr/bin/whoami` schreiben, es funktioniert auch. Ich brauchte aber root-Zugriff für ein cgi und hab suidperl aktiviert. Jetzt geht der Befehl nicht _mehr_.
Also bei Dir läuft Dein Webserver als root ? Ein Webserver steht normal im Internet und _da_ ist Sicherheit wichtig!
Nein, mein cgi läuft als root. Apache lässt sich als root gar nicht starten... Du hast das Thema nicht von Anfang an mitverfolgt? Ich wollte mir OpenWebMail installieren, das läuft als cgi und bietet per Web Zugriff auf lokale Mails. Dafür braucht es natürlich Zugriff auf /etc/passwd , /var/spool/mail ,... Das heisst: Der Webserver (apache als nobody:nogroup) ruft webmail.pl (suid root:root) auf. Suid funktioniert aber nicht bei Scripten. Also habe ich suidperl installiert, das erlaubt das "hochsetzen" der Rechte. Jetzt gehen aber andere Sachen nicht mehr, die vorher noch gingen, weil perl mir Restriktionen aufzwingt, die ohne suidperl nicht vorhanden waren. Mich stört einfach, daß man perl geradezu kaputtkonfigurieren muß, weil es ungefragt Features aktiviert, die auf vielen Systemen keinen Sinn machen.
Siehe oben: Ich greife auf Befehle zu, die in der Bash funktionieren, und Perl baut mir wieder "Wenn" und "Aber" davor.
s.o Bash != PerlCGI
Falsch. Dafür sind die `-Zeichen ja da. PerlCGI != Bash aber `PerlCGI` = Bash Naja, im Groben.
Wenn folgendes Skript auf der Konsole läuft, muß bei meinem Perl nicht der kpl. Pfad angegeben werden. ( ohne -T ).
#!/usr/local/bin/perl -w
$out = `ls` print $out;
Der Taint Modus ist also auch nicht explicit an!
Ich denke mal, du benutzt auch perl und nicht suidperl und hast nicht mitbekommen, worum es geht. Obiges funktioniert bei mir auch, und auch der Taint-Mode ist aus. Dann setze ich die Rechte von 0755 auf 6755, und es funktioniert nicht mehr, und auch der Taint-Mode ist jetzt aktiv. Das cgi ist erst wieder zum Laufen zu bekommen durch Einfügen der Zeile $ENV{'PATH'} = '/bin:/usr/bin:/usr/sbin:/usr/local/bin'; um explizit Code in /bin ausführen zu dürfen (Dort liegt "ls"). Und das nervt mich. Nicht, daß es einen Taint-Mode gibt oder das er unnütz wäre, sondern daß er ungefragt(!) aktiv wird, weil ich etwas ganz anderes umkonfiguriert habe.
Das ist ja richtig, aber unsicher. Außerdem soll man grundsätzlich absolute Pfade in seinen Skripten angeben (wenn man im System arbeitet jedenfalls, bei CGI nimmt man oft auch relative Pfade)
Ich habe einen absoluten Pfad eingegeben. Das nützt nichts.
Bei PHP z.B. ist das ähnlich. Wenn Du das willst mußt auch die php.ini abändern und freischalten das Du außerhalb Deines htdocs etwas ausführen willst.
...was ich natürlich schon lange getan habe. safe_mode... ;-)
Warum installierst Du keinen M$ Webserver? Das ist kommerz Software, da kannst Du anschliessend beschweren.
Nutze ich ebenfalls. Hat alles Vor- und Nachteile. Gruß, Ratti -- http://www.gesindel.de | Fontlinge | Die Schriftenverwaltung für Windows