Schreibprobleme

[SebastianJu]

Hallo,

ich habe eine Code geschrieben der lokal auf dem XAMMP-Server funktioniert aber nicht mehr auf dem Webspace.

    $filehandle = fopen('../sitemap.xml', 'w+');  
    if ($filehandle === FALSE) {  
      die("File Open Error");  
    }  
    $xml = $sitemapclass->output();  
    fputs ($filehandle, $xml);  
    fclose ($filehandle);

Damit erhalte ich die Meldung:

Warning: fopen(../sitemap.xml) [function.fopen]: failed to open stream: Permission denied in /var/www/web43/web/cron/cron1hour.php  on line 43
File Open Error

Ich habe gelesen es ist ein Rechteproblem aber der Ordner web in dem die Datei erstellt werden soll hat die Rechte: 775 und eigentlich sollte der Server doch ohnehin schreiben dürfen.

Ich habe dann versucht davor:
touch('../sitemap.xml');

zu schreiben aber das bringt die Meldung.

Warning: touch() [function.touch]: Unable to create file ../sitemap.xml because Permission denied in /var/www/web43/web/cron/cron1hour.php  on line 42

Ich habe PHP Safe Mode testweise abgeschaltet aber das hat auch nichts geändert.

Woran kann das liegen?

Übrigens wer einen kostenlosen Cronjob sucht: http://www.cron-job.org

[jobo]

Hallo,

Ich habe gelesen es ist ein Rechteproblem aber der Ordner web in dem die Datei erstellt werden soll hat die Rechte: 775 und eigentlich sollte der Server doch ohnehin schreiben dürfen.

775 heißt "der Rest der Welt" darf lesen, nicht schreiben oder ausführen. Wie wäre es mit 776, auch für die übergenordneten Ordner?

Gruß

jobo

[SebastianJu]

775 heißt "der Rest der Welt" darf lesen, nicht schreiben oder ausführen. Wie wäre es mit 776, auch für die übergenordneten Ordner?

Das hab ich jetzt mal probiert und habe diese Meldung erhalten:

Forbidden

You don't have permission to access /cron/cron1hour.php on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Nach dem Rückändern kam die alte Meldung wieder.

Dann habe ich 777 probiert und damit geht es. Aber wieso gilt der Server als Öffentlich?

Ist 777 jetzt ein Sicherheitsrisiko? Will damit eigentlich nur meine google sitemaps erstellen.

[cygnus]

Hallo :)

Ist 777 jetzt ein Sicherheitsrisiko?

Ja.

Ich habe vor einiger Zeit auch einige Test mit Rechte-Einstellungen gemacht.
Versuche es mal mit 757.

mfg
cygnus

[jobo]

Hallo,

Ich habe vor einiger Zeit auch einige Test mit Rechte-Einstellungen gemacht.

was soll 757 bringen. Wenn jedermann rwx-Rechte hat, hat das die Gruppe allemal. 757 gibts garnicht, so wie ich das verstehe, weil 7 für jedermann das 5 für die Gruppe überregiert?

Gruß

jobo

[cygnus]

Hallo :)

was soll 757 bringen. Wenn jedermann rwx-Rechte hat, hat das die Gruppe allemal. 757 gibts garnicht, so wie ich das verstehe, weil 7 für jedermann das 5 für die Gruppe überregiert?

Klingt logisch.
chmod 757 wird aber doch immer wieder aus den verschiedensten Gründen empfohlen.

mfg
cygnus

[dedlfix]

Hi!

was soll 757 bringen. Wenn jedermann rwx-Rechte hat, hat das die Gruppe allemal.

Es heißt nicht "jederman" sondern "alle anderen". Oder laut man-Page zu chmod:
the user who owns it (u), other users in the file's group (g), other users not in the file's group (o)

757 gibts garnicht, so wie ich das verstehe, weil 7 für jedermann das 5 für die Gruppe überregiert?

Tut's nicht. Wenn du also Mitglied der Gruppe der Datei bist, darfst du sie lesen und ausführen. Ansonsten musst du dich unter einer Kennung anmelden, die nicht Gruppenmitglied ist (oder der Owner sein), um schreiben zu können.

Lo!

[Der Martin]

Hallo,

Es heißt nicht "jederman" sondern "alle anderen". Oder laut man-Page zu chmod:
the user who owns it (u), other users in the file's group (g), other users not in the file's group (o)

das ist ein interessantes Detail, wusste ich auch noch nicht.

757 gibts garnicht, so wie ich das verstehe, weil 7 für jedermann das 5 für die Gruppe überregiert?
Tut's nicht. Wenn du also Mitglied der Gruppe der Datei bist, darfst du sie lesen und ausführen. Ansonsten musst du dich unter einer Kennung anmelden, die nicht Gruppenmitglied ist (oder der Owner sein), um schreiben zu können.

Es wäre also auch möglich, die Rechte so zu setzen (577), dass jeder in die Datei schreiben darf, nur ich als Besitzer nicht? Das ist ja schräg ... ;-)

Ciao,
 Martin

[dedlfix]

Hi!

Es wäre also auch möglich, die Rechte so zu setzen (577), dass jeder in die Datei schreiben darf, nur ich als Besitzer nicht? Das ist ja schräg ... ;-)

Ja. Es gibt 256 Kombinationen von Rechten - darunter sind bestimmt auch ein paar unsinnige.

Aber warum zum $fluchRezipient wird so oft und unnötigerweise mit dem Ausführen-Recht um sich geworfen. Ist die Sicherheitslücke durch unnötige Schreibrechte noch nicht groß genug?

Lo!

[Der Martin]

n'Abend,

Es wäre also auch möglich, die Rechte so zu setzen (577), dass jeder in die Datei schreiben darf, nur ich als Besitzer nicht?
Ja. Es gibt 256 Kombinationen von Rechten

eigentlich sind es 2^3 * 2^3 * 2^3 = 2^9 = 512 Kombinationen.

darunter sind bestimmt auch ein paar unsinnige.

Würde ich auch so sehen.

Aber warum zum $fluchRezipient wird so oft und unnötigerweise mit dem Ausführen-Recht um sich geworfen.

Wird es? Ich habe das in meinem Beispiel nur aus Gewohnheit mit eingeschlossen, ich wollte das Beispiel allgemein halten. Klar, für reine Dokumente oder Konfigurationsdateien ist 666 de facto gleichwertig mit 777, für PHP-Scripte auch, weil sie aus der Sicht des OS nicht als ausführbar gelten. Perl-Scripte in der Regel schon, den Unterschied finde ich auch bemerkenswert.

Ist die Sicherheitslücke durch unnötige Schreibrechte noch nicht groß genug?

Vermutlich ...

Ciao,
 Martin

[dedlfix]

Hi!

Ja. Es gibt 256 Kombinationen von Rechten
eigentlich sind es 2^3 * 2^3 * 2^3 = 2^9 = 512 Kombinationen.

Also ich bekomme mit 8 Bit nur 256 Varianten hin. Aber es sind nicht 8 Bit (Denkfehler meinerseits) sondern 4*3 - schließlich gibt es noch drei Bits für Setuid, Setgid und das Sticky Bit - also 4096 Möglichkeiten.

[...] für reine Dokumente oder Konfigurationsdateien ist 666 de facto gleichwertig mit 777, für PHP-Scripte auch, weil sie aus der Sicht des OS nicht als ausführbar gelten. Perl-Scripte in der Regel schon, den Unterschied finde ich auch bemerkenswert.

Üblicherweise wird bei PHP vom Apachen zuerst PHP gestartet, das dann die Datei liest. Bei Perl wird das Script gestartet, das über die Shebang das Perl aktiviert. Das ginge prinzipiell mit PHP auch so und mit Perl auch umgekehrt. Doch so wie es üblich ist, passt das besser zur Philosophie beider Sprachen. PHP ist eingebetteter Code, Beim Perl-Script ist alles Code.

Lo!

[jobo]

Hallo,

Dann habe ich 777 probiert und damit geht es. Aber wieso gilt der Server als Öffentlich?

Was meinst du mit "öffentlich".

Ist 777 jetzt ein Sicherheitsrisiko? Will damit eigentlich nur meine google sitemaps erstellen.

Keine Ahnung, warum du in die Datei schreiben willst. Aber eigentlich muss du für den Zugriff ja sowieso auf dem Server sein, also per FTP ein script hochgeladen haben. Ich denke mal, es ist kein Sicherheitsrisiko. Vielleicht aber dein kostenloser Server nicht so wirklich "Kosten" los?

Gruß

jobo

[SebastianJu]

Dann habe ich 777 probiert und damit geht es. Aber wieso gilt der Server als Öffentlich?

Was meinst du mit "öffentlich".

Mit öffentlich meine ich den Rechtebereich. Besitzer, Gruppe und Öffentlich. Wieso gilt der Server als öffentlich?

Ist 777 jetzt ein Sicherheitsrisiko? Will damit eigentlich nur meine google sitemaps erstellen.

Keine Ahnung, warum du in die Datei schreiben willst. Aber eigentlich muss du für den Zugriff ja sowieso auf dem Server sein, also per FTP ein script hochgeladen haben.

Ein Skript habe ich ja auch hochgeladen per ftp. Und das php-skript soll die Datei erstellen.

Ich denke mal, es ist kein Sicherheitsrisiko.

Na dann ist ja gut...

Vielleicht aber dein kostenloser Server nicht so wirklich "Kosten" los?

Ist nicht mein Service. Den hab ich nur gefunden als ich einen Cronjob brauchte aber keinen auf dem Hosting hatte.

[jobo]

Hallo,

Dann habe ich 777 probiert und damit geht es. Aber wieso gilt der Server als Öffentlich?

Was meinst du mit "öffentlich".

Mit öffentlich meine ich den Rechtebereich. Besitzer, Gruppe und Öffentlich. Wieso gilt der Server als öffentlich?

Vielleicht verstehst du das nicht ganz? Schau doch mal: http://de.wikipedia.org/wiki/Unix-Dateirechte#Grundlegende_Rechte.

Öffentlich heißt, dass jeder Nutzer oder User auf dem Server Zugriff hat, soweit das nicht von einem übergeordneten Verzeichnis unterbunden wird. Und das wir bei Deinem Webspace der Fall sein.

Gruß

jobo

[Zuzu]

Dann habe ich 777 probiert und damit geht es. Aber wieso gilt der Server als Öffentlich?

Was meinst du mit "öffentlich".

Mit öffentlich meine ich den Rechtebereich. Besitzer, Gruppe und Öffentlich. Wieso gilt der Server als öffentlich?

"Öffentlich" ist mir als Bezeichnung noch nicht untergekommen, vermutlich, weil das eine überaus schlechte Übersetzung ist. Benutze besser "alle", das trifft es genauer.

Die Dateirechte beziehen sich davon unabhängig nicht auf den Server, sondern auf das System. Auch auf einem Rechner, der nicht als Server fungiert, kennen Linux & Co. Datei- bzw. Benutzerrechte. In diesem Kontext gilt dann auch das "öffentlich", lies: alle – alle Benutzer des Systems, also alle Benutzer, die der Benutzerverwaltung des Systems bekannt sind.
Auf deine Datei kannst du nur dann schreibend zugreifen, wenn du "allen" Schreibrechte erteilst, weil der Webserver (das Programm, nicht die Maschine) mit einem eigenen Benutzerkonto läuft. Die Datei gehört aber dir, nicht dem Webserver, ergo musst du dem Webserver explizit Schreibrechte einräumen. Und in deinem Fall geht das nur, wenn du "allen" Schreibrechte gibst.

Ist 777 jetzt ein Sicherheitsrisiko? Will damit eigentlich nur meine google sitemaps erstellen.

Mal abgesehen davon, dass Sitemaps eh fürn Arsch sind, weil der Googlebot die Arbeit nach wie vor einwandfrei selbst macht: Ein Risiko ist das nur insofern, als dass jeder andere Kunde, dessen Kram auf dem Server gehostet wird, jetzt in deiner Datei rumschreiben kann.

[SebastianJu]

Ist 777 jetzt ein Sicherheitsrisiko? Will damit eigentlich nur meine google sitemaps erstellen.

Mal abgesehen davon, dass Sitemaps eh fürn Arsch sind, weil der Googlebot die Arbeit nach wie vor einwandfrei selbst macht: Ein Risiko ist das nur insofern, als dass jeder andere Kunde, dessen Kram auf dem Server gehostet wird, jetzt in deiner Datei rumschreiben kann.

Jeder kann rumschreiben? Aber hoffentlich erst wenn er den FTP-Zugang rausgefunden hat oder?
Ansonsten mit den Rechten für alle habe ich schon verstanden. Dann ist doch aber die Frage wieso der Server nicht einer entsprechenden Gruppe zugeordnet ist die die Rechte hat oder? So wie es jetzt ist hat der Server der ja wie ein Hausherr ist ja nur die Rechte die jeder x-beliebige von der Straße auch hat. Das macht doch keinen Sinn oder? Schließlicht macht der Server die Webseite ja aus...

Mit Sitemaps habe ich bisher ganz gute Erfahrungen gemacht. Besonders wenn es darum geht alle Seiten einer Webseite zu indizieren und auch möglichst schnell scheint das mit den Sitemaps gut zu klappen. Besonders wenn man die jeden Tag einmal per Ping an die großen Sumas schickt.

[Der Martin]

Hallo,

[...] dass jeder andere Kunde, dessen Kram auf dem Server gehostet wird, jetzt in deiner Datei rumschreiben kann.
Jeder kann rumschreiben? Aber hoffentlich erst wenn er den FTP-Zugang rausgefunden hat oder?

was heißt "rausgefunden"? Andere Kunden, die auf diesem Server "wohnen", haben doch bereits ihren FTP-Zugang. Aber der spielt ja hier auch gar keine Rolle - es geht um die Möglichkeit, dass z.B. ein fremdes PHP-Script in *deinem* Webspace wildern kann, wenn du "everyone" Schreibzugriff einräumst.

Ansonsten mit den Rechten für alle habe ich schon verstanden. Dann ist doch aber die Frage wieso der Server nicht einer entsprechenden Gruppe zugeordnet ist die die Rechte hat oder?

Welche Gruppe wäre das dann? - Angenommen, auf dem Server werden 400 Webspaces gehostet. Dann gibt es zwar 400 Kunden, die aber in der Rechteverwaltung keine Rolle spielen, denn es gibt nur einen Webserver und nur einen FTP-Server.

So wie es jetzt ist hat der Server der ja wie ein Hausherr ist ja nur die Rechte die jeder x-beliebige von der Straße auch hat. Das macht doch keinen Sinn oder?

Doch, unbedingt. Der Webserver ist auf der Maschine nämlich nur ein popeliger Prozess, der sogar so wenig Privilegien wie nur möglich haben sollte, um die Stabilität der Maschine nicht gefährden zu können.

Schließlicht macht der Server die Webseite ja aus...

Ja. Aber aus der Sicht des Systemadministrators ist der Webserver nur ein Prozess unter vielen.

So long,
 Martin

[Zuzu]

Ein Risiko ist das nur insofern, als dass jeder andere Kunde, dessen Kram auf dem Server gehostet wird, jetzt in deiner Datei rumschreiben kann.

Jeder kann rumschreiben? Aber hoffentlich erst wenn er den FTP-Zugang rausgefunden hat oder?

Falls du mit "_dem_ FTP-Zugang" deinen FTP-Zugang meinst: Nein, grundsätzlich _jeder_, der Zugang zum Dateisystem hat. Einschränkung bezüglich FTP siehe weiter unten.

wieso der Server nicht einer entsprechenden Gruppe zugeordnet ist die die Rechte hat oder? So wie es jetzt ist hat der Server der ja wie ein Hausherr ist ja nur die Rechte die jeder x-beliebige von der Straße auch hat. Das macht doch keinen Sinn oder?

Auf einem Hosting-Server liegen in der Regel die Seiten von mindestens mehreren Hundert, gerne auch weit über Tausend Kunden, und der Webserver-Prozess muss logischerweise Zugriff auf die Dateien aller Kunden haben.

Ein eigener Webserver-Prozess für jeden Kunden, also hunderte, tausende Prozesse auf derselben Maschine, würde Webhosting teilweise ad absurdum treiben, denn der günstige Preis des Hostings liegt in der geteilten Nutzung preiswerter Hardware begründet.

Die übliche Vorgehensweise ist, dem Webserver Zugang zu Dateien über die Gruppe "alle Benutzer" zu gewären, so, wie es bei dir ist (und nochmal: "alle" bedeutet nicht "jeder x-beliebige von der Straße", "alle" bedeutet alle Benutzer, die das System kennt, also quasi "jeder x-beliebige Bewohner des Hauses").
In dieser Konfiguration könnte jeder Kunde, der über einen FTP-Zugang zum Rechner verfügt, die Dateien anderer Kunden einsehen und, wie bei deiner Sitemap, gegebenenfalls beschreiben. In der Praxis steht dem eine Sicherung durch den FTP-Server im Wege, er lässt nur Zugriffe auf das jeweilige Benutzerverzeichnis zu, nicht darüber hinaus.

Es gäbe in der Tat die Möglichkeit, für jeden Kunden eine eigene Gruppe anzulegen und den Webserver-Prozess dieser Gruppe zuzuordnen. Der Zugriff für alle könnte dann gänzlich gesperrt werden. Das wird leider selten gemacht, vermutlich, weil früher ein Prozess nur einer kleinen Anzahl an Gruppen zugeordnet werden konnte, und heute heißt es dann "das haben wir immer so gemacht".
Zudem würde da, wo Skripte im Rahmen des Webserver-Prozesses ausgeführt werden (wie bei dir) und nicht als eigenständige Prozesse mit den Rechten des Kunden, auch diese Gruppenbeschränkung nicht viel bringen, denn der Dateizugriff des Kunden erfolgt ja über den Webserver-Prozess.
Probier's mal: Du kannst mit einem einfachen PHP-Skript höchstwahrscheinlich die Dateien aller anderen Kunden auf dem Rechner auslesen (und meist noch weit mehr). Du brauchst dazu lediglich die ganz normalen Funktionen zum Auflisten des Verzeichnisinhalts bzw. zum Dateizugriff.

Schließlicht macht der Server die Webseite ja aus...

Das hat damit nichts zu tun. Der Webserver ist per se ein Sicherheitsrisiko für das System, wie jeder Prozess, der einen Zugang für die Außenwelt bereitstellt. Jeder Prozess sollte im System so wenig Rechte wie möglich haben, damit ein abstürzender, amoklaufender oder kompromitierter Prozess nicht das ganze System mit in den Abgrund reisst – und bei Prozessen, die mit der bösen Außenwelt kommunizieren, gilt das doppelt und dreifach.

[SebastianJu]

Danke für die ausführliche Erklärung!

[fastix®]

Moin!

Aber wieso gilt der Server als Öffentlich?

Der Server wird als Dienst vom root gestartet, der auf dem System gottgleiche Rechte hat, geht nicht anders, weil nur root Dienste starten darf, die an den Ports 1-1024 auf Anforderungen lauschen. Das wäre ein extremes Sicherheitsproblem wenn nicht der Apache nach dem Listen am Port den Benutzer und die Gruppe wechseln würde.

Zu welchem Benutzer Dein Apache wechselt kannst Du

in der Apache-Konfiguration
mit etwas Intelligenz in /etc/passwd erkennen. In der Standardkonguration unter vielen Linux-Distributionen ist es der Benutzer wwwrun, Gruppe www.

Die ultimative Antwort auf Deine Frage bekommst Du, wenn Du durch ein PHP-Skript in einem Verzeichnis mit den Rechten 0777 eine Datei anlegen lässt und Dir anschaust wem und welcher Gruppe diese gehört.

fastix

[dedlfix]

Hi!

Ich habe gelesen es ist ein Rechteproblem aber der Ordner web in dem die Datei erstellt werden soll hat die Rechte: 775 und eigentlich sollte der Server doch ohnehin schreiben dürfen.

Die Rechte allein sind - wenn das entscheidende Recht nicht in allen drei Werte gleich gesetzt ist - ohne wirkliche Aussage, wenn nicht bekannt ist, welcher Nutzer zugreifen will und in welcher Gruppe er sich befindet. Beziehe also in deine Überlegungen auch immer die Besitzverhältnisse der Datei und des Verzeichnisses (beim Löschen, Anlegen, Umbenennen - alles was eine Schreiboperation im Verzeichnis ist) sowie den zugreifenden Nutzer (und seine Grupppenzugehörigkeiten) ein.

Ich habe PHP Safe Mode testweise abgeschaltet aber das hat auch nichts geändert.

Der Safe Mode erzeugt Meldungen, die sich explizit auf ihn beziehen. Der ist also in deinem Fall nicht beteiligt.

Lo!