CHMOD ändern geht bei bestimmten Dateien nicht
 

Hallo,
in meinem Webspace tritt manchmal folgendes Problem auf. Ich lade über mein Forum oder mein Wiki (laufen alle über PHP) Dateien in meinen Webspace.

Will ich diese mittels FTP wieder mal sichern lassen sich nicht alle herunterladen.

Was mir auffällt ist, dass genau diese Dateien nicht CHMOD 644 sondern 600 gestellt sind. Ein ändern ist mir aber auch nicht möglich. Auch nicht bei den Dateien, die sich korrekt (mit dem gleichen Programm upgeloadet) wieder herunterladen lassen und auch auf 644 stehen.

Nachdem mir dies eben bei meinem Weblog, Wiki und Forum passiert ist, kann es ja nicht ganz an der Software liegen, oder?

Oder ist dies ein Fehler meines Providers?

Über jeden kleinen Ratschlag wäre ich dankbar, da ich mich ohne Sicherung meiner Dateien nicht ganz wohl fühle....

MfG
Robert

Durch schlecht programmierte Scripten kommt es leider zu deinem beschriebenen Problem.
Und zwar wird durch das Ausführen vom Script der erstellten Datei oder Bilder die Rechte vom Apacheserver gegeben und nicht von deinem User, meistens www-data.
Deshalb kann dein User die Datein nicht verändern und auch die Rechte nicht aktualisieren.

Nach einem Dateiupload oder ähnlichem sollte das Script einen chmod oder chgrp/chown machen, tun aber die wenigsten Scripten.
Deinem Provider trifft keine Schuld, die Entwickler musst du in den Hintern treten.

Sloter

Danke für die - nicht so erfreuliche - Antwort.

Heisst das ich muß meinen Webspaceprovider bitten den CHMOD zu ändern?

Ich bin nur ein bisschen erstaunt, da ich dieses Problem ja nicht nur mit einem Programm habe. Aber mag sein, dass die wenigsten User ihre Daten auch sichern ;-( und daher noch keiner so ein Problem geäußert hat!

MfG
Robert

Noch eine Ergänzung bzw. Frage.

Über das Wiki kann ich aber meine upgeloadeten Files auch wieder löschen. D.h. es gibt die Möglichkeit des Zugriffs darauf. Warum dann nicht wenn ich mitels FTP direkt einsteige?

Oder stehe ich da jetzt auf der Laienleitung?

MfG
Robert

Nochmal zur Erklärung:

PHP läuft unter dem User des Webservers (nobody, www-data o.Ä.). Daher gehören Daten die du per PHP auf den Server lädst oder erstellst, diesem User.
Wenn du per FTP auf den Server zugreifst verwendest du deinen FTP User. Dieser hat keine Berechtigung auf die Datei zuzugreifen, da sie ihm ja nicht gehört.

Lösung: Du kannst für die Datei die du per PHP erstellt hast, auch mit PHP die Berechtigungen ändern oder sie löschen (das geht weil die Datei ja dem Webserver/PHP User gehört). Mach die Datei per PHP einfach kurzfristig für "alle" lesbar/beschreibbar, dann kannst du sie mit dem FTP User herunterladen/löschen.

1, Ja, aber jedesmal wenn du neue Datein über PHP raufladest müssen die Rechte neu gesetzt werden.

2, Nö, kommt sehr oft vor im Supportbereich eines Providers und auf ein Backup wird gerne vergessen.

M@rio hat es auch schön erklärt.

Sloter

Danke für eure fachmännische Unterstützung. Noch eine Frage: Was meinst du mit "mach per PHP alles lesbar/schreibbar". Brauche ich "nur" ein PHP-Script, dass mir die Sache umschreibt?
Sorry, wenn ich da zu laienhaft frage - aber in solche Dinge arbeite ich mich erst langsam ein.
Aber wenn dem so ist, dann schaue ich mir gerne mal an wie man per PHP CHMODs durchführt. Das könnte ich sicherlich öfter brauchen.

Re: CHMOD ändern geht bei bestimmten Dateien nicht
 

Ja, bei einigen Provider tritt dieses Problem auf. Wenn über PHP generierte Dateien sich nicht über FTP löschen lassen, ist aber definitiv der Server nicht richtig konfiguriert. Ich würde einmal den Support auf dieses Problem hinweisen.

Und was soll da Falsch sein am Server?

Sloter

So wie es aussieht werden die Dateien auf den oberen Server mit zu niedrigen Rechten (600 statt 644) erstellt.

Warum das so ist weiss ich aber auch nicht, da dieses Problem auf meinen Servern bisher nicht aufgetretten ist. Ich habe es gerade nochmal auf meinen cPanel/RHEL Server probiert und konnte die über PHP erstellten Dateien mittels FTP Client herunterladen oder löschen

Die bisher beste Lösung gegen diese Rechte Probleme habe ich auf Ensim basierten System gesehen. Dort läuft jede Website in ihrer eigenen Chroot Umgebung mit eigener Benutzerkennung, wobei auch Apache diese verwendet :eek:

Jetzt muß ich doch noch einmal nachfragen.

Die PHP-Software läuft auf meinem Webspace (bei einem externen Provider, ist eine Linuxmaschine, PHP 4.2.3). Warum macht es jetzt einen Unterschied ob ich mittels dieses PHP Programms Dateien abrufe oder lösche oder wenn ich direkt mittels FTP auf diese Datei zugreifen will. Sollte ich da nicht die gleichen Rechte haben?

Ich bin ja auch in meinem PHP Programm (das auch auf diesem Webspace läuft) der Admin.

Oder mißverstehe ich da etwas in der Rechtverwaltung? :confused:

Wenn es euch zu mühselig mit mir wird, vielleicht gibts ja auch eine gute Website mit einer Erklärung rund um dieses Thema.

Danke für alle bisherigen Postings.
MfG
Robert

Ja, normalerweise sollte man auf diese Dateien auch über FTP zugreifen können. Da der Apache Webserver die Dateien aber nur mit chmod 600 anlegt, hat der FTP Server kein Recht darauf zuzugreifen.

Das ist ein Fall für den Support

Ich habe mich jetzt mal an den Programmierer des Wiki gewandt. Der meinte, dass er einen CHMOD nicht einbauen könne, da ansonsten es auf einem Server mit save_mode nicht funktionieren würde. Wobei meiner einer den save_mode nicht laufen hat.

MfG
Robert

Eher für den Coder, Apache macht nur das, was ihm angeschafft wird und entscheidet nicht selbst über Dateirechte.
Imho ist da das Script der Auftraggeber ;)

Sloter

Die Apache Installation auf cPanel schreibt die Daten automatisch mit den richtigen Dateirechten. Der obere Fehler liegt definitiv an einen Serverproblem.

Bisher sind solche Rechtefehler nur bei 2 meiner Kunden aufgetreten. Ich dachte urspünglich das es ein Problem auf Sun Solaris Systemen ist.

Jetzt habe ich das ganze auch auf meinen Debian 3.1 Testserver ausprobiert. Die Dateien werden auch dort automatisch mit chmod 644 erzeugt.

Der save_mode läuft am Server selber. Er soll verhindern das einer der User (z.b. Du) fremde Dateien öffnen kann.

Ich könnte das Problem in der Zwischenzeit auf einen Debian 3.0 Server reproduzieren. Es hat etwas mit den /tmp Verzeichnis des Servers zu tun.

Während des Fileuploads werden die Dateien im /tmp Verzeichnis zwischengespeichert um danach in das entsprechende Webverzeichnis umkopiert zu werden. Beim Speichern im /tmp Verzeichnis verlieren sie aber einige Rechte und genau hier liegt das Problem.

Bei cPanel dagegen hat jede Website ihr eigenes /tmp Verzeichnis und verwendet nicht das Servereigene.

Danke für deine Bemühungen. Das heisst, es liegt an der Konfiguration meines Providers?
Ich werde ihn mal auf diesen Thread aufmerksam machen und schauen, was er dazu sagt....
MfG
Robert

Ja und Nein. Ich habe jetzt einiges durchprobiert.

Solange die Dateien ohne /tmp Zwischenspeicherung geschrieben werden, erzeugt Apache sie mit 644 rechten. Allerdings sobald in /tmp zwischengespeichert wird (üblicherweise bei Uploads) stellen sich die Rechte bei vielen Installationen auf 600. Eine der Ausnahmen sind cPanel basierende Systeme. Dort bekommt jede Website automatisch ihr eigenes /tmp Verzeichnis. Die hochgeladenen Dateien werden mit 644 zurückgeschreiben und können über FTP heruntergeladen oder gelöscht werden.

Wie cPanel das macht konnte ich bisher aber nicht herausfinden. Zumindest in den Konfigurationsdateien fand ich nichts ungewöhnliches. Es kann auch durchaus sein das Apache selber modifiziert wurde, da cPanel seine eigene Apache Build mitbringt oder besser gesagt in bester Gentoo Manier selbst kompiliert :eek:

Die Userkennung selber spielt übrigens dabei kaum eine Rolle. Selbst bei cPanel werden die Dateien mit der Kennung "nobody" geschreiben und können dank ihrer 644 Rechte vom FTP Server gelesen/gelöscht werden.

Nur am /tmp kann es aber nicht liegen.
Unter Debian/Confixx hat jeder User sein eigenes /phptmp und die Rechte werden trotzdem falsch gesetzt.

Sloter

Dann bessert entweder cPanel oder Red Hat Enterprise Linux die Rechte nach. Wenn ich etwas Zeit finde werde ich es einmal auf einer Standalone Red Hat Installation ausprobieren.

Ich habe aus Interesse auch nachgeschaut welches System der Autor des Wiki verwendet: comawiki.org is running "Apache/1.3.31 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.8 FrontPage/5.0.2.2634a mod_ssl/2.8.18 OpenSSL/0.9.6b". Diese Kennung erinnert mich irgendwie an meinen cPanel Server :D ;)

Danke für eure Versuche und Tests - das ist wirklich ein toller Support.
Als Laie steht man da etwas hilflos da.

Ich habe mal Entwickler und Provider damit beschäftigt und sie auch auf diesen Thread zum nachlesen hingewiesen.

Ich hoffe es kommt zu einer Lösung.

Kann es eigentlich auch mit der PHP Version zu tun haben? Mein Provider läuft dzt. noch 4.2.3 und stellt dzt. auf 4.3.6/7 um...

MfG
Robert

chown ...
chmod 744

Mein Provider überlegt sich noch einiges.

Dafür hat der Entwickler meines Wikis ein Update herausgebracht, dass die Dateirechte korrekt setzt.

Damit bin ich mal fürs erste beruhigt. Bin aber trotzdem neugierig, wer/was denn nun wirklich das Problem war? Mal sehen, was mir mein Provider noch antwortet.

MfG
Robert