Und genau diese festen Werte gehen nicht. Diese Werte funktionieren in *deren* Umgebung, aber nicht global, je nachdem, *wie* der Server aufgesetzt ist.alter schwede hat geschrieben:Profihost hat geantwortet:
Das muß das CMS nicht wissen, es führt global eine umask 022 oder einen chmod 644 durch.
Problem mit FTP-Zugriffsrechten und Apache
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
Ja, ich hab's ueber Backend getestet, weil ich glaube, du das im ersten Posting geschrieben hast, dass es da Probleme gibt. ftp benutze ich dafuer eigentlich gar nicht.alter schwede hat geschrieben: @christa
Ja, alles wurde konfiguriert.
Lädst du über den Backendupload hoch? Ich habe es gerade noch einmal getestet und die files kommen immer mit 600 an. Wenn ich etwas per FTP hochlade hat es auch bei mir 644. Mir geht es hier um den Backend-Upload.
-
- Beiträge: 65
- Registriert: So 13. Jun 2004, 01:27
- Kontaktdaten:
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
@alter schwede: Ich habe gerade noch eine viel bloedere Frage ... von welcher Contenido-Version reden wir gerade?
@timo: ich habe gerade gesehen, dass bei 4.4.4 in der Datei functions.upl.php so etwas steht:
und bei der 4.5.2, die ich hier habe, taucht kein chmod auf. Falls alter schwede in der Tat die 4.5.2 benutzt, stellt sich die Frage, was dort geaendert werden muss, dass chmod eben doch ausgefuehrt wird (also an welcher Stelle). So tief stecke ich leider nicht drin.
@timo: ich habe gerade gesehen, dass bei 4.4.4 in der Datei functions.upl.php so etwas steht:
Code: Alles auswählen
if (@move_uploaded_file($userfile[$i],$cfgClient[$client]['upl']['path'].$path.$userfile_name[$i])) {
chmod($cfgClient[$client]['upl']['path'].$path.$userfile_name[$i],0644);
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
-
- Beiträge: 65
- Registriert: So 13. Jun 2004, 01:27
- Kontaktdaten:
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
Noch nicht verzweifeln ... da sie geschrieben haben, 644 sei kein Problem, habe ich sie nun gebeten, dies zu aendern. Ich muesste nur genauer wissen, wo das gemacht wird, denn sie meinten, in der php.ini waere das nicht moeglich. timo, wo genau muss serverseitig die umask gesetzt werden? Evtl. in der httpd.conf?alter schwede hat geschrieben:@christa
Habe gerade die Diskussion im ProfiHost-Forum gelesen.
-
- Beiträge: 65
- Registriert: So 13. Jun 2004, 01:27
- Kontaktdaten:
@christa
Danke für deinen Einsatz. Mit viel Glück stellen sie es vielleicht tatsächlich um.
Über ProfHost kann man hier wirklich nicht meckern. Die versuchen wirklich zu helfen. ProfiHost schrieb:
Hast du eine Idee wo man die Einstellungen vermutlich abändern müsste?
FTP-Uploads laufen wie gesagt problemlos. Nur Uploads über PHP sind dort Standartmäßig auf 600 gesetzt!
Werdet Ihr die Chmod eventuell wieder in die Uploadskripte aufnehmen?
Danke für deinen Einsatz. Mit viel Glück stellen sie es vielleicht tatsächlich um.
Über ProfHost kann man hier wirklich nicht meckern. Die versuchen wirklich zu helfen. ProfiHost schrieb:
@timoWenn Sie mir sagen, wie wir PHP dazu bewegen können, die Scripte standardmäßig als 644 upzuloaden - tue ich dies gerne... werde morgen aber gerne auch noch einmal suchen. Bei php als Modul ist es 644 bei php als Binary nicht... - so scheint es.
Hast du eine Idee wo man die Einstellungen vermutlich abändern müsste?
FTP-Uploads laufen wie gesagt problemlos. Nur Uploads über PHP sind dort Standartmäßig auf 600 gesetzt!
Werdet Ihr die Chmod eventuell wieder in die Uploadskripte aufnehmen?
-
- Beiträge: 6284
- Registriert: Do 15. Mai 2003, 18:32
- Wohnort: Da findet ihr mich nie!
- Kontaktdaten:
Im Prinzip muß an jeder Stelle, an der Dateiuploads passieren könnten, ein entsprechendes chmod gesetzt werden. Bessere Alternative: Entweder alles über Contenido hochladen oder alles über FTP, aber nicht gemischt.Halchteranerin hat geschrieben:und bei der 4.5.2, die ich hier habe, taucht kein chmod auf. Falls alter schwede in der Tat die 4.5.2 benutzt, stellt sich die Frage, was dort geaendert werden muss, dass chmod eben doch ausgefuehrt wird (also an welcher Stelle). So tief stecke ich leider nicht drin.
chmod war noch nie drin, soweit ich weiß, und wird dort auch nie wieder reinkommen, da es einfach falsch wäre.@timo
Wie stehen den die Chancen, dass ihr den Chmod wieder in die functions.upl.php rein nehmt?
Das ist so nicht ganz richtig - php läuft unter dem Apache und dieser hat wohl eine umask gesetzt, die 600 erzeugt. Ein Weg ist es, die umask für den Apache zu verändern, oder das Upload-Verzeichnis mit einem Sticky-Bit zu setzen.@timo
Hast du eine Idee wo man die Einstellungen vermutlich abändern müsste?
FTP-Uploads laufen wie gesagt problemlos. Nur Uploads über PHP sind dort Standartmäßig auf 600 gesetzt!
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
timo, ein bisschen schreiben wir aneinander vorbei.
Es sind die Zeilen 213-214 in der functions.upl.php von Contenido 4.4.4.
Das Problem, was alter schwede hat, ist, dass er beim neuen Contenido die Dateien hochlaedt und diese die Rechte 600 haben.timo hat geschrieben:Bessere Alternative: Entweder alles über Contenido hochladen oder alles über FTP, aber nicht gemischt.
Doch, das war drin, ich hab's oben zitiert, mach's aber gerne nochmal.timo hat geschrieben: chmod war noch nie drin, soweit ich weiß, und wird dort auch nie wieder reinkommen, da es einfach falsch wäre.
Code: Alles auswählen
if (@move_uploaded_file($userfile[$i],$cfgClient[$client]['upl']['path'].$path.$userfile_name[$i])) {
chmod($cfgClient[$client]['upl']['path'].$path.$userfile_name[$i],0644);
Ich kenne mich nicht so genau mit Apache aus, soll heissen, ich habe da nie gross etwas herumkonfiguriert. Was Profihost meinte, ist, dass es wohl zwei Moeglichkeiten gibt, php laufen zu lassen, und zwar als Modul und als Binary, wobei das bei Profihost als Binary laeuft. Die Preisfrage ist nun: wieso werden bei ftp-Uploads die Rechte auf 644 und bei Contenido-Uploads (also uebers Backend) mit der CVS-Version die Rechte auf 600 gesetzt? Bzw. wie und wo kann das bei php als Binary eingestellt werden, dass die Uploads ueber Contenido auch die Rechte 644 haben?timo hat geschrieben: Das ist so nicht ganz richtig - php läuft unter dem Apache und dieser hat wohl eine umask gesetzt, die 600 erzeugt. Ein Weg ist es, die umask für den Apache zu verändern, oder das Upload-Verzeichnis mit einem Sticky-Bit zu setzen.
-
- Beiträge: 6284
- Registriert: Do 15. Mai 2003, 18:32
- Wohnort: Da findet ihr mich nie!
- Kontaktdaten:
Nein, das ist ja richtig so: Das Recht "600" ist ja okay, solange alles in Contenido bleibt. 600 bedeutet, daß der Besitzer (also Contenido über PHP) lesen und schreiben darf.Halchteranerin hat geschrieben:timo, ein bisschen schreiben wir aneinander vorbei.Das Problem, was alter schwede hat, ist, dass er beim neuen Contenido die Dateien hochlaedt und diese die Rechte 600 haben.timo hat geschrieben:Bessere Alternative: Entweder alles über Contenido hochladen oder alles über FTP, aber nicht gemischt.
Das kann man pauschal nicht sagen...dazu muß man sich hinsetzen und schauen, wie der Server konfiguriert ist.Ich kenne mich nicht so genau mit Apache aus, soll heissen, ich habe da nie gross etwas herumkonfiguriert. Was Profihost meinte, ist, dass es wohl zwei Moeglichkeiten gibt, php laufen zu lassen, und zwar als Modul und als Binary, wobei das bei Profihost als Binary laeuft. Die Preisfrage ist nun: wieso werden bei ftp-Uploads die Rechte auf 644 und bei Contenido-Uploads (also uebers Backend) mit der CVS-Version die Rechte auf 600 gesetzt? Bzw. wie und wo kann das bei php als Binary eingestellt werden, dass die Uploads ueber Contenido auch die Rechte 644 haben?
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
DAS wiederum 'scheint' nicht zu stimmen, denn alter schwede sagt, dass bei ihm die Bildergalerie nicht funktioniert, d.h. die Thumbnails werden nicht generiert, solange die Dateien das Recht 600 haben. Ob das nun stimmt oder nicht, weiss ich nicht, denn auf dem Server habe ich kein 4.5.2, nur lokal, und da habe ich keine Lust, mit der (bislang gut funktionierenden) Konfiguration herumzuspielen.timo hat geschrieben:Nein, das ist ja richtig so: Das Recht "600" ist ja okay, solange alles in Contenido bleibt. 600 bedeutet, daß der Besitzer (also Contenido über PHP) lesen und schreiben darf.
-
- Beiträge: 6284
- Registriert: Do 15. Mai 2003, 18:32
- Wohnort: Da findet ihr mich nie!
- Kontaktdaten:
Doch doch, das kann schon richtig sein, wenn die Dateien über FTP hochgeladen wurden! Dann haben die Dateien nämlich den FTP-Benutzer als Owner. Kommt aber andererseits auch wieder darauf an, wie die Thumbnails erzeugt werden.Halchteranerin hat geschrieben:DAS wiederum 'scheint' nicht zu stimmen, denn alter schwede sagt, dass bei ihm die Bildergalerie nicht funktioniert, d.h. die Thumbnails werden nicht generiert, solange die Dateien das Recht 600 haben.timo hat geschrieben:Nein, das ist ja richtig so: Das Recht "600" ist ja okay, solange alles in Contenido bleibt. 600 bedeutet, daß der Besitzer (also Contenido über PHP) lesen und schreiben darf.
-
- Beiträge: 65
- Registriert: So 13. Jun 2004, 01:27
- Kontaktdaten:
@timo
Leider kenne ich mich in der Materie nicht genügend aus. Wieso wäre das denn falsch?? Immerhin würde es auf jedem System funktionieren und 644 ist bestimmt kein großes Sicherheitsrisiko!?
Das Sticky-Bit habe ich Testhalber mal für das Uploadverzeichnis und alle Unterverzeichnisse gesetzt. Leider ohne Wirkung. (Kann jeder mit dem Standartbildmodul testen ...)
In welcher Datei würde denn die Unmask für den Apache gesetzt?
Theoretisch gebe ich dir Recht. Praktisch gibt es diese Fehler bereits mit dem Standartbildmodul. Ist chmod auf 600 wird keine Bild angezeigt !!! Auf 644 klapt es problemlos. Ich denke daher nicht das 600 okay ist.Nein, das ist ja richtig so: Das Recht "600" ist ja okay, solange alles in Contenido bleibt. 600 bedeutet, daß der Besitzer (also Contenido über PHP) lesen und schreiben darf.
Es wird ja alles über das Backend hochladen. Momentan muss ich leider nach dem Upload immer ins FTP-Programm und die chmod 644 durchführen, da es sonst die Fehler gibt. Würde man die chmod-Funktion wieder in den Uploadcode aufnehmen, wäre zumindest von dieser Seite aus alles in Ordnung. Schließlich wollen die CMS-Kunden im Regelfall alles über das CMS hochladen.Im Prinzip muß an jeder Stelle, an der Dateiuploads passieren könnten, ein entsprechendes chmod gesetzt werden. Bessere Alternative: Entweder alles über Contenido hochladen oder alles über FTP, aber nicht gemischt.
Das stimmt doch nicht. (siehe Posting von Christa)chmod war noch nie drin, soweit ich weiß, und wird dort auch nie wieder reinkommen, da es einfach falsch wäre.
Leider kenne ich mich in der Materie nicht genügend aus. Wieso wäre das denn falsch?? Immerhin würde es auf jedem System funktionieren und 644 ist bestimmt kein großes Sicherheitsrisiko!?
Das Sticky-Bit habe ich Testhalber mal für das Uploadverzeichnis und alle Unterverzeichnisse gesetzt. Leider ohne Wirkung. (Kann jeder mit dem Standartbildmodul testen ...)
In welcher Datei würde denn die Unmask für den Apache gesetzt?
-
- Beiträge: 6284
- Registriert: Do 15. Mai 2003, 18:32
- Wohnort: Da findet ihr mich nie!
- Kontaktdaten:
Wurde das Bild über FTP oder über Contenido hochgeladen?alter schwede hat geschrieben:@timo
Theoretisch gebe ich dir Recht. Praktisch gibt es diese Fehler bereits mit dem Standartbildmodul. Ist chmod auf 600 wird keine Bild angezeigt !!! Auf 644 klapt es problemlos. Ich denke daher nicht das 600 okay ist.Nein, das ist ja richtig so: Das Recht "600" ist ja okay, solange alles in Contenido bleibt. 600 bedeutet, daß der Besitzer (also Contenido über PHP) lesen und schreiben darf.
Es gibt keine Direktive in der Konfiguration des Apaches, sondern das wird über das Environment vom Server konfiguriert.In welcher Datei würde denn die Unmask für den Apache gesetzt?