chmod 777 und Internal Server Error

[Manuel B.]

Hi,
ich versuche grade folgendes.
Ich hab im cgi-bin ein Verzeichnis angelegt, da soll per PHP ein Script reinkopiert werden. Dazu muss PHP auf dieses Verzeichnis natürlich schreibrechte haben, also chmod 777

Allerdings produziert der Apache einen Internal Server Error, wenn ein Verzeichnis innerhalb cgi-bin ein chmod 777 bekommen hat.

also in meinem Fall: /cgi-bin/verzeichnis/script.pl

bei chmod 777 verzeichnis -> Internal Server Error
bei chmod 755 verzeichnis -> Script läuft

Wie kann ich das umgehen? Per shell-script ist mir das klar, aber ich würde das gerne mit PHP machen, da dann das Setup der Software einfacher ist.

System:
suse 9.1
Apache/2.0.48
Perl 5.8.1
Confixx 3.0.7

Da die Software später auf möglichst jedem Webspace laufen soll, will ich nichts an der Serverconfig ändern. Sonst könnte ich das Problem ganz anders lösen ;)

[Tobias Kloth]

Hallo Manuel,

Allerdings produziert der Apache einen Internal Server Error, [...]

was sagt das error_log?

Grüße aus Nürnberg
Tobias

[Manuel B.]

Hi,

was sagt das error_log?

ein popeliges
Premature end of script headers:

[Christoph Schnauß]

hallo,

bei chmod 777 verzeichnis -> Internal Server Error
bei chmod 755 verzeichnis -> Script läuft
Wie kann ich das umgehen?

Ich verstehe deine Frage nicht. 755 ist doch für ein Verzeichnis, das Perl-Scripts enthält, die als CGI-Scripts arbeiten sollen, eine gute Wahl. Warum willst du daraus 777 machen?

System:
suse 9.1
Apache/2.0.48
Perl 5.8.1
Confixx 3.0.7

Confixx ist wurscht in diesem Zusammenhang (es sei denn, du sprichst von einem Webverzeichnis, das nicht auf deinem lokalen Rechner liegt). Die anderen sinds eigentlich auch, weil dein Problem woanders liegt. /cgi-bin brauchst du im wesentlichen für Perl-Scripts, das ist Konvention und Gewohnheit, aber man kann dem Server auch beibringen, daß er aus anderen Verzeichnissen heraus CGI-Scripts ausführen lassen sollt (hatten wir grade gestern hier in irgendeinem Thread). PHP braucht sich um /cgi-bin nicht zu kümmern.

Nur zur Rekapitulation: du läßt über PHP ein Perl-Script überhaupt erst erstellen, das dann in einem Unterverzeichnis von /cgi-bin liegt und von dort aus arbeiten soll? Darf ich fragen, warum du das so machst?

Da die Software später auf möglichst jedem Webspace laufen soll, will ich nichts an der Serverconfig ändern. Sonst könnte ich das Problem ganz anders lösen ;)

Hm. No comment. Sicher scheint nur, daß du die "Dimension" deiner Anfrage schamhaft verschwiegen hast.

Insgesamt würde ich empfehlen, daß du dich mit der Frage nach den "Rechten" nochmal gründlicher beschäftigst. Es kann sein, daß der Benutzer, der übers Web auf dein /cgi-bin zugreift, ein völlig anderer ist als der, der mit PHP erst das Script zusammenstellen läßt.

Grüße aus Berlin

Christoph S.

[Manuel B.]

Hi,

Ich verstehe deine Frage nicht. 755 ist doch für ein Verzeichnis, das Perl-Scripts enthält, die als CGI-Scripts arbeiten sollen, eine gute Wahl. Warum willst du daraus 777 machen?

Um per PHP Scripte reinzukopieren

Confixx ist wurscht in diesem Zusammenhang (es sei denn, du sprichst von einem Webverzeichnis, das nicht auf deinem lokalen

Ich habs nur dazugeschrieben, weil COnfixx teilweise ein recht seltsames verhalten bei der Rechtevergabe zeigt. z.B. kann ich in einem Verzeichnis, das vpn PHP erzeugt wurde (also als owner wwwrun.www hat keine weiteren Verzeichnisse anlegen lassen durch PHP)

Nur zur Rekapitulation: du läßt über PHP ein Perl-Script überhaupt erst erstellen, das dann in einem Unterverzeichnis von /cgi-bin liegt und von dort aus arbeiten soll? Darf ich fragen, warum du das so machst?

Ich lasse die nicht erstellen, ich kopiere die nur.
Ich lade per Formular ein Zip-File auf den Server, das wird dann per PHP entpackt und die Dateien in verschiedene Verzeichnisse verteilt.
Und da sind eben auch PERL-Scrpte dabei.

Hm. No comment. Sicher scheint nur, daß du die "Dimension" deiner Anfrage schamhaft verschwiegen hast.

Keine Ahnung, was du mit "Dimension" meinst, aber das CMS, das ich grad schreibe sollte möglich ohne Dedicated laufen ;)

Insgesamt würde ich empfehlen, daß du dich mit der Frage nach den "Rechten" nochmal gründlicher beschäftigst. Es kann sein, daß der Benutzer, der übers Web auf dein /cgi-bin zugreift, ein völlig anderer ist als der, der mit PHP erst das Script zusammenstellen läßt.

Ich kenne meine Rechte ~ggg~
Also, der Apache läuft mir suExec (webXX.webXX), PHP arbeitet mit wwwrun.www
Und irgendwie muss ich es fertigbringen, das wwwrun.www in das cgi-bin von webXX.webXX schreiben darf (und bei bedarf das script auch wieder löschen).
Als alternative hab ich mir schon überlegt, ein neues Verzeichnis anzulegen um Userspace und dann per .htaccess diese für CGI nutzbar zu machen. Dann könnte ich die rechte per Script setzen, wie ich sie brauche.

[Christoph Schnauß]

hallo,

Nur zur Rekapitulation: du läßt über PHP ein Perl-Script überhaupt erst erstellen, das dann in einem Unterverzeichnis von /cgi-bin liegt und von dort aus arbeiten soll? Darf ich fragen, warum du das so machst?
Ich lasse die nicht erstellen, ich kopiere die nur.

Das läuft auf dasselbe hinaus. Warum nimmst du dafür nicht auch gleich Perl?

Sicher scheint nur, daß du die "Dimension" deiner Anfrage schamhaft verschwiegen hast.
Keine Ahnung, was du mit "Dimension" meinst, aber das CMS, das ich grad schreibe

Aha, ertappt ;-) Genau sowas vermutete ich.

Als alternative hab ich mir schon überlegt, ein neues Verzeichnis anzulegen um Userspace und dann per .htaccess diese für CGI nutzbar zu machen. Dann könnte ich die rechte per Script setzen, wie ich sie brauche.

Wahrscheinlich die richtige Lösung.

Grüße aus Berlin

Christoph S.

[Manuel B.]

Hi,

Das läuft auf dasselbe hinaus. Warum nimmst du dafür nicht auch gleich Perl?

Fällt aus, da PERL nur eine Erweiterung ist, aber nicht zwingend für das CMS erforderlich. Aber wenns vorhanden ist, und der Anwender es nutzen will, soll die Installationsroutine der Plugins natürlich vollautomatisch gehen und nicht das der Anwender hinterher noch die PERL-Scripts von Hand kopieren muss.
Und das gleiche soll ja mit Python später auch noch funktioneren.

[xwolf]

Hi,

Ich hab im cgi-bin ein Verzeichnis angelegt, da soll per PHP ein Script reinkopiert werden. Dazu muss PHP auf dieses Verzeichnis natürlich schreibrechte haben, also chmod 777

Allerdings produziert der Apache einen Internal Server Error, wenn ein Verzeichnis innerhalb cgi-bin ein chmod 777 bekommen hat.

also in meinem Fall: /cgi-bin/verzeichnis/script.pl

bei chmod 777 verzeichnis -> Internal Server Error
bei chmod 755 verzeichnis -> Script läuft

Richtig so!!!!

Du hast offenbar einen Provider mit einem vernünftigen Admin.

suexec (und phpsuexec) verbieten die Ausführung von Skripten, die in einem
Verzeichnis liegen, welches für die jeden schreibbar sind.

Das Skript und das Verzeichnis (inkl. Baum) in der es liegt darf nur von einem einzigen User, nämnlich dem User der Webdomain änderbar sein.
Alle anderen User und die Group dürfen nur r-x haben.

Schau dir mal die Doku zu suexec bzw phpsuexec an.
Wahrscheinlich brauchst du in dem Virtual Host-Eintrag nur die beiden Zeilen
anzuschauen um zu wissen, welche Userkennung möglich ist.

(Apache 2:)
SuexecUserGroup
suPHP_UserGroup

(Apache 1:)
User
Group

Ciao,
  Wolfgang

[Manuel B.]

Hi,

Du hast offenbar einen Provider mit einem vernünftigen Admin.

Das nehm ich als Lob. Das ist ein Rootserver, den ich selbst konfiguriert hab ;)

anzuschauen um zu wissen, welche Userkennung möglich ist.

Ja, das ist auch nicht das Problem. Dadurch, das PHP als Modul eingebunden wird, werden Verzeichnisse halt als Apache-Benutzer angelegt.

Jetzt werd ich zusätzlich php5 als CGI installieren.

Umgekehrt werd ich wohl meine Ordnerstruktur des CMS überarbeiten. Dann hat der Benutzer aber mehr Arbeit beit setzen der Dateirechte.