[gelöst] Datein nach PHP Upload immer chmod 600 statt chmod 664

[elitepilot]

es ist ein 1200 Euro CMS, was da drauf liegt. D.h ich kann da nix umschreiben.

[joximu]

Dann sag dem Hersteller, er soll das einbauen - schliesslich sollte man sich nicht drauf verlassen, wie die Besitzerverhältnisse von hochgeladenen Dateien sind.

Alternativen:
oben schon geschrieben: neueres PHP ausprobieren (Stichwort dotdeb),
PHP selbst kompilieren oder patchen
per auto-prepend-file eine angepasste funktion moveuploadedfile einbauen... (geht vielleicht???)

[DaSilva]

Ich habe das selbe Problem seitdem ich auf ispCP setze.
Vorher unter VHCS 2.4.8 RC1 hatte ich das nicht.
Sowohl ein Kunde als auch ich selbst musste das schon miterleben.
Z. B. bei Joomla 1.5.2 habe ich ein Galerieplugin und wenn ich da Bilder hochlade haben sie immer 600 statt wenigstens 644 wie vorher bei VHCS.
Debian Etch war sowohl vorher als auch jetzt im Einsatz, ebenso die gleiche Version von PHP.
Kann daran also nicht liegen.
Der Benutzer passt auch.
Was gibt es noch für Lösungsvorschläge?

[jmeyerdo]

DaSilva Wrote:Debian Etch war sowohl vorher als auch jetzt im Einsatz, ebenso die gleiche Version von PHP.

Bist Du 100% sicher, dass es vorher die gleiche PHP-Version (und gleiche fastcgi-Version/Konfiguration) war?

Bei mir trat der gleiche Fehler auf und war nach joximu's Tipp durch ein PHP-Update dann behoben.

Viele Grüße, Jens

[joximu]

@DaSilva
VHCS hat php anders angesprochen - hochgeladene Dateien gehörten austomatisch dem apache-benutzer und php lief mit den Rechten vom apache Benutzer, also gab's keine Probleme.

Also: entweder php updaten (danke @jmeyerdo - ich wusste nicht, dass es tatsächlich gefixt wurde... man konnte es nur hoffen, da niemand mehr auf das Ticket reagiert hat) oder /var und /tmp auf unterschiedliche Partitionen tun oder die Applikation umschreiben oder apache-mpm-prefork und mod-php einsetzen und mit der fehlenden Benutzertrennung leben.

/J

[DaSilva]

Kann ich jetzt noch im laufenden Betrieb eine neue Partition extra für /tmp anlegen?
Wenn ja, wie und wie groß sollte die gewählt sein?
Welche Dienste muss ich danach alle neustarten damit der Fehler behoben wird?
Danke.

[joximu]

Kommt drauf an, welches Dateisystem du gewählt hast. Wenn du die ersten zwei Fragen nicht selbst beantworten kannst, würde ich das von jemandem machen lassen.
Falls keine Platz mehr da ist für neue Partitionen, müsste man bestehende verkleinern und das wird dann schon etwas heikel.
Im Prinzip reicht es - falls überhaupt notwendig - den Apache neu zu starten.

Meine Empfehlung für neue Server: jeweils /var auf ne eigene Partition. Das system benötigt bei mir (Testserver) 1.5 GB - dann noch etwas Reserve dazu (abhängig von Festplattengrösse) und der Rest für /var, swap etc...

Gruss J

[DaSilva]

Na gut, dann hoffe ich eben darauf, dass die neue Version von PHP bald für Debian Etch freigegeben wird.
Ab welcher Version sollte das denn repariert sein, 5.2.4?
Manuell kann man das nicht machen schätze ich!?
Warum dauert das sowieso so lange bei Debian?
Version 5.2.5 ist doch schon seit einem halben Jahr stable!

[joximu]

laut Bugreport (Link siehe oben) ist es auch in 5.2.4 - aber wenn jmeyerdo mit den dotdeb Paketen arbeitet - und die haben meines Wissens 5.2.5, dann sollte es also im 5.2.5 behoben sein.

Wie du mit dotdeb weiterkommst, steht auch in einzelnen Forenbeiträgen.

Leider weiss ich nicht, ob und wann Debian sein PHP aktualisiert, es gäbe noch andere behobene Bugs...

Gruss J

[DaSilva]

Müsste alles funktionieren wenn ich so vorgehe:

Code:

apt-get build-dep php5
apt-get install checkinstall
cd Verzeichnis-mit-PHP5-Quellen
./configure
make
checkinstall
dpkg -i neues-PHP-Paket

???

Wie sieht es bei späteren "apt-get update && apt-get upgrade" aus?
Kann der die Version dann aktualisieren?