Hallo alle zusammen,
ich habe eine Frage zum Thema Perl/CGI und Shellsimulation: ich arbeite derzeit an einem Programm um bestimmte Dateien automatisch zu konvertieren.
Mein Problem ist nun, dass ein Programm, welches ich für diese Konvertierung aufrufe, zwar die benötigten Dateien generiert wenn es in einem xterm oder auf der Konsole manuell aufgerufen wird (und auch wenn ein Perl- oder Shellscript, das manuell aufgerufen wird, dieses Programm aufruft), nicht aber wenn der Aufruf über den Browser erfolgt (egal ob mit exec, system oder den backticks) erfolgt.

Um das ganze nochmal deutlich zu machen, hier die "Signalketten":
Manueller Aufruf->Perl/Bash-Script->Programm [funktioniert]
Browser->Perl-Script(CGI)->Programm [funktioniert nicht]

Auch wenn ich in der zweiten Variante noch ein bash-script dazwischenhänge, geht es nicht.

Meine Frage ist nun ob jemand weiß, wie ich die Gegebenheiten eines manuellen Aufrufs aus der Shell heraus exakt simulieren kann bzw. ob dies möglich ist.

Vielen Dank für eine Antwort,

Es liest sich so, als wäre es eigentlich kein Programmierproblem, sondern ein Rechteproblem. Das CGI-Skript wird vom Standarduser des Webservers (häufig nobody) ausgeführt. Dieser hat allerdings die wenigsten Rechte.
Du musst sicherstellen, dass das Programm, das Du ausführen willst, auch für ALLE ausführbar sein muss (Stichwort chmod 755).

Ansonsten musst Du probieren, mal was zu suexec herauszufinden... (Für Apache-Webserver: http://httpd.apache.org/docs/suexec.html )
Man sollte allerdings auch bedenken, dass dies ein gewisses Sicherheitsrisiko darstellt!\n\n

<!--EDIT|renee|1089376647-->

suexec ein sicherheitsrisiko? inwiefern? ist es nicht ohne suexec bei weitem unsicherer?

[quote=jan,09.07.2004, 19:20]suexec ein sicherheitsrisiko? inwiefern? ist es nicht ohne suexec bei weitem unsicherer?[/quote]
Eigentlich schon.
suEXEC verhindert eben gerade, dass sämtliche Scripts nicht unter wwwrun (Webserver Rechte) laufen. Um die Rechte einzuschränken und auf einen User zu beschränken wurde suEXEC erfunden. Dass dies ein Sicherheitsrisiko ist glaube ich nicht, zumal es ja entwickelt wurde, um eine höhere Sicherheit zu gewährleisten.

eben, so habe ich mir das auch erklärt. aber vielleicht ist's ja auch ein mißverständnis, vielleicht meinte renee etwas vollkommen anderes, zB die ausführung ohne suexec, die dann wiederum eben gerade die user-rechte nicht hat und deshalb sich von der shell-ausführung unterscheidet. klingt irgendwie logischer, oder?\n\n

<!--EDIT|jan|1089397323-->

@Dasypus: Prüfe vor allem auch, ob der Benutzer, unter dem der Server läuft, überhaupt Daten in das Zielverzeichnis schreiben darf. Ich nehme eher dann, dass das Programm zwar läuft, aber die Ausgabe nicht funktioniert. (Eventuell auch nicht das Einlesen der Daten.)

@jan: Deine Frage wird direkt unter dem Link beantwortet, den renee gepostet hat:
[quote= ,[URL=http://httpd.apache.org/docs/suexec.html]http://ht... properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.
[/quote]
Übersetzt: Korrekt eingesetzt kann dieses Feature deutlich die Risiken senken, die auftauchen, wenn man Benutzern erlaubt, eigene CGI- und SSI-Programme zu entwickeln und auszuführen. Wenn suEXEC allerdings nicht richtig konfiguriert wird, kann es einige Probleme verursachen und möglicherweise sogar zusätzliche Sicherheitslücken in Ihrem Rechner verursachen. Wenn Sie sich nicht im Umgang mit setuid root Programmen und ihren Sicherheitsaspekten auskennen, empfehlen wir Ihnen dringend, auf den Einsatz von suEXEC zu verzichten.

oh, interessant. was wären denn die möglichen sicherheitslücken, die sich da auftun? ich kenne mich nämlich nicht im geringsten mit setuid-programmen und ihren sicherheitsrelevanten problemen aus...

Ich kenne mich wiederum nicht mit der suEXEC-Konfiguration aus, da ich bisher immer einen Bogen darum machen konnte. :)

Aber dass Programme, die unter root-Account laufen, eher ein Risiko darstellen als Programme unter einem weniger privilegierten Account, dürfte klar sein. Und für suEXEC muss der Apache unter root laufen, sonst kann er nicht für Skripte die UID wechseln. Wenn man die suEXEC-Konfiguration nicht richtig macht, laufen dann möglicherweise Skripte unter root, die eigentlich (nicht-privilegierten) Usern gehören - da kann man den Usern gleich das Root-Passwort geben. Und je nach Sicherheit des Skriptes den Besuchern der Webseite gleich mit.\n\n

<!--EDIT|Dubu|1089403410-->

mhja, aber ja nur der main-process, die childs, die nachher ja die eigentliche arbeit übernhemen und die prozesse starten, laufen wiederum als www (oder wwwrun oder nobody oder wen auch immer man dafür nutzt).
naja, wäre dennoch mal interessant, das zu wissen. ich habe meine server mit suexec konfiguriert, um eine vergleichbare sache zu haben wie puretec/schlund, da ich öfter von hier nach da verschoben habe, sodass ich gerne ähnliche bedingungen haben wollte. trotzdem bin ich - und die leute, mit denen ich arbeite, die sind natürlich auch dabei - der einzige, der scripte hochlädt, d.h. die gefahr ist begrenzt, da keine untrusted scripts hineingelangen. dennoch natürlich interessant, was man denn nun tun könnte, um das ganze noch besser abzusichern!

ahh, hm, ja, ok, aber da ist suexec dann wiederum ziemlich streng, d.h. zB laufen scripts nur, wenn die user, als der sie ausgeführt werden sollen und der user, dem sie gehören, identisch sind. und wenn sie nicht für andere schreibbar sind. und so weiter. und root ist als script-ausführer imho ohnehin ausgeschlossen (siehe letzter post)