Hallo Mattos,
lies mal den ganzen Thread, da steht drin, wie es gehen kann (inkl. der Vorgehensweise mit chown). Nach wie vor ist es kein Contenido-Bug, sondern ein Problem des Providers. Das einzige, was wir an Contenido umbauen können, sind Workarounds für Probleme, die durch eine mangelhafte Implementation seitens PHP bzw Konfiguration des Providers verursacht wird.
Grüße,
Timo[/b]
Richtiger Owner für Verzeichnisse und Dateien!
Re: Richtiger Owner für Verzeichnisse und Dateien!
timo hat geschrieben:Die häufigste Ursache für Probleme mit Contenido scheint zu sein, daß die Dateien und Verzeichnisse falsche Berechtigungen und Besitzer haben.
Es ist wichtig, daß derselbe Benutzer konsistent das gesamte Contenido-Verzeichnis besitzt. Beispiel:
Es kommt oftmals vor, daß Contenido den Besitzer "A" hat, die Dateien, die jedoch durch das Contenido bearbeitet werden, den Besitzer "B" haben. Sofern der SAFE_MODE in PHP ausgeschaltet ist, ist das kein Problem, sofern die Dateiberechtigungen stimmen, aber da in den meisten Fällen der SAFE_MODE an ist, darf Contenido als "A" nicht auf Dateien von "B" zugreifen, obwohl die Berechtigungen stimmen. Wichtig ist daher, daß sämtliche Verzeichnisse und Dateien denselben Besitzer haben!
Nachfolgendes kleines Script prüft, ob irgendwelche Verzeichnisse und/oder Dateien einen unterschiedlichen Besitzer haben. Einfach in eine Textdatei (z.b. permissioncheck.php) kopieren, hochladen und auf dem Webserver über einen Browser aufrufen.
Code: Alles auswählen
<?php echo "<pre>"; checkOwnerDir(getcwd()."/"); echo "checkPerms beendet."; echo "</pre>"; function checkOwnerDir ($from_path) { $old_path = $from_path; if (is_dir($from_path)) { chdir($from_path); $myhandle=opendir('.'); while (($myfile = readdir($myhandle))!==false) { if (($myfile != ".") && ($myfile != "..")) { if (fileowner($myfile) != getmyuid()) { $ownerInfo = posix_getpwuid(fileowner($myfile)); echo "<font color="red">Fehler:</font> Der Besitzer "".$ownerInfo["name"]."" der Datei ".$from_path.$myfile." ist unterschiedlich zu dem Besitzer ("".get_current_user()."") des aktuellen Scriptes. Stellen Sie sicher, daß die Datei den gleichen Besitzer (owner) erhält wie das Script.\n"; } if (is_dir($myfile)) { checkOwnerDir ($from_path.$myfile."/"); chdir($from_path); } } } closedir($myhandle); } chdir($old_path); return; } ?>
Habe 4.3 beta auf Strato installiert, wie angegeben. Bei dem Versuch einen PHP-Datei (index.php) über den Browser zu starten, bekomme ich eine Fehlermeldung, dass ich keine Berechtigung dafür habe. Alle Dateien gehören dem User ftp. Das ist ja auch klar, da über ein FTP Programm die Dateien installiert wurden. Der Versuch das o.a. Programm hochzuladen und zu starten scheitert am gleichen Problem.
Wie kann nun über den FTP Client, der über kein CHOWN verfügt (nur CHMOD) das Problem gelöst werden ? Habe auch versucht alle Rechte zu setzen, bringt aber auch nichts.
auf Spurensuche
@suupamuh: danke für den hinweis. ich habe mir auch smartFTP runtergeladen und ein bisschen probiert. für welche ordner/dateien hast du die Rechte geändert? für die drei bei mir von permissioncheck.php monierten dateien (pseudo-cron.log, move_articles.php.job und move_old_stats.php.job) kann ich die rechte nicht ändern. oder meintest du den upload-ordner des entsprechenden mandanten?suupamuh hat geschrieben:
Also ich hab das selbe Problem, das ich den besitzer nicht ändern kann. gestern hab ich mir mal ein Ftp PRog namens Smart ftp runtergeladen, damit kann man auch die Besitzerrechte ändern.
Ich kann meine Besitzerrechte zwar nicht ändern, ich hab aber ein wenig rumprobiert und folgende einstellungen führten zu einer Notlösung.
Schreibrechte 773 und unten sind zwei Checkbuttons namens uid und GID. Diese hab ich angeklickt .
Die Folge. Der Upload funktioniert bei mir nun, ich kann zwar nur ins Uploadverzeichniss uppen und keine neuen Ordner anlegen, ausserdem kommen immer noch ein paar fehlermeldungen, aber uploaden kann ich jetzt, wenn gleich es im moment nicht Perfekt ist.
Nur ein Versuch den du mal probieren kannst, aber kein Patentrezept. leider.
an alle nochmal die frage: habe inzwischen verstanden, dass mein provider safe_mode off schalten müsste. das klappt wohl nicht. also suche ich einen anderen weg. ich dachte, ich könnte bilder per ftp hochladen und sie erschienen dann auch im auswahlfenster bei einem container, der mit einem bild-modul bestückt ist. ist nicht! warum eigentlich nicht? manuell die bilder mit ftp hochladen, wäre für mich akzeptabel. nur auswählen muss man sie eben können. an die experten: geht sowas?
bin für eure hilfe sehr dankbar! gruß, chris
chown-Problem
Hallo Leute,
ich habe natürlich auch das oben beschrieben Problem. Besitzer der Dateien war web2 (ftpuser) von der Gruppe ftponly, allerdings ist der ausführende User wwwrun von der Gruppe www. Der Server läuft mit safe_mode off, allerdings hat das auch noch nix gebraucht - die Seiten waren weiß (im Editor, Vorschau, Frontend). Nun habe ich zum Testen den Admin des Servers gebeten, alle Dateien (komplettes contenido, cms und conlib) auf wwwrun / www zu setzen, direkt nachdem ich contenido 4.3.2b installiert hatte, ohne Änderungen des Editors oder ähnliches, und schon lief alles ohne Probleme!!!
Leider konnte ich jetzt nix mehr an den Dateien ändern. Daher habe ich einen cronjob installiert, der mir die Dateien aus einem Verzeichnis des Users web2 in das Installationsverzeichnis kopiert - und dabei selbstverständlich die Rechte ändert. Der cronjob syncronisiert die Verzeichnisse alle 2 min - was reichen sollte. Vielleicht hilft das ja ein wenig.
Gruß, Benny
ich habe natürlich auch das oben beschrieben Problem. Besitzer der Dateien war web2 (ftpuser) von der Gruppe ftponly, allerdings ist der ausführende User wwwrun von der Gruppe www. Der Server läuft mit safe_mode off, allerdings hat das auch noch nix gebraucht - die Seiten waren weiß (im Editor, Vorschau, Frontend). Nun habe ich zum Testen den Admin des Servers gebeten, alle Dateien (komplettes contenido, cms und conlib) auf wwwrun / www zu setzen, direkt nachdem ich contenido 4.3.2b installiert hatte, ohne Änderungen des Editors oder ähnliches, und schon lief alles ohne Probleme!!!
Leider konnte ich jetzt nix mehr an den Dateien ändern. Daher habe ich einen cronjob installiert, der mir die Dateien aus einem Verzeichnis des Users web2 in das Installationsverzeichnis kopiert - und dabei selbstverständlich die Rechte ändert. Der cronjob syncronisiert die Verzeichnisse alle 2 min - was reichen sollte. Vielleicht hilft das ja ein wenig.
Gruß, Benny
noch ein paar Fragen ...
hallo, im Forum ist dieses Thema leider weit gestreut, habe gerade unter
http://contenido.de/forum/viewtopic.php ... c&start=15
nochmal einige Details eingestellt. Darin vor allem an timo und benny einige Anfragen. Wäre nett, wenn Ihr mal reinschaut.
Danke.
Chris
http://contenido.de/forum/viewtopic.php ... c&start=15
nochmal einige Details eingestellt. Darin vor allem an timo und benny einige Anfragen. Wäre nett, wenn Ihr mal reinschaut.
Danke.
Chris
Wenn man sich daran hält, kommt man zum Erfolg. Ein SSH Zugang ist von nöten, da man sonst nicht alle benötigten Schritte vornehmen kann. Nach Änderung der PHP ini den Apache neustart nicht vergessen.
Es hilft zusätzlich auch wenn bilder nicht angezeigt wurden den jeweiligen Ordner nochmal in der Dateiverwaltung zu öffnen.
Es hilft zusätzlich auch wenn bilder nicht angezeigt wurden den jeweiligen Ordner nochmal in der Dateiverwaltung zu öffnen.
timo hat geschrieben:In der Unix-Welt gibt es zu jeder Datei einen Besitzer und die Rechte für diese Datei. Mit chmod hat das nichts zu tun, sondern mit chown. Ein Beispiel für ein übliches Directory Listing unter Linux:
Obiges Beispiel zeigt folgendes:Code: Alles auswählen
drwxr-xr-x 10 alek202 users 600 Jul 2 11:37 . drwxr-xr-x 5 wwwrun wwwrun 120 Jun 23 12:59 .. drwxr-xr-x 2 alek202 users 112 Jun 26 15:53 css drwxr-xr-x 5 alek202 users 120 Jun 26 15:53 upload
Der Besitzer für das aktuelle Verzeichnis (.) und die Verzeichnisse css sowie upload ist der Benutzer alek202 in der Gruppe users. Das "drwxr-xr-x" gibt die Rechte für diese Datei an. Mit chmod beeinflusst man die Rechte, mit chown den Besitzer sowie die Gruppe.
Folgende Annahme: Ein Script mit dem Benutzer "alek202" versucht auf eine Datei, die dem Benutzer "klaus303" gehört, zuzugreifen. Dies wird jedoch durch den SAFE_MODE verhindert, sodaß "alek202" trotz voller Zugriffsrechte auf dem Dateisystem nicht auf die Datei von "klaus303" zugreifen darf. Genau das passiert bei einem Upload: Die Datei wird hochgeladen, und technisch sieht es so aus, daß PHP die Datei in ein temporäres Verzeichnis legt. Genau DAS passiert aber mit den Rechten des Webservers: Die Datei, die hochgeladen wurde und jetzt in einem temporären Verzeichnis liegt, gehört z.b. "wwwrun" (Der Benutzer, unter dem der Webserver läuft). Das Script, welches die Datei aber bearbeiten muß, gehört "alek202" - und das geht durch den SAFE_MODE in die Hose. Laut PHP-Manual sollte die Funktion "move_uploaded_file" zwar die UID-Checks übergehen, in der Praxis geht das aber leider doch nicht.
Was ist also jetzt zu tun?
Die einfachste Möglichkeit ist sicherlich, den SAFE_MODE abzuschalten. Wer dies nicht möchte oder kann, muß entweder Contenido komplett als Benutzer "wwwrun" (so heißt der Benutzer des Webservers meistens) laufen lassen (z.b. chown -R wwwrun contenido-4.3.1b) oder in der Datei php.ini die Direktive "safe_mode_gid" auf "on" zu setzen. "safe_mode_gid" ist dann nicht mehr ganz so streng, und auf obiges Beispiel angewandt würde das bedeuten: Wenn "alek202" und "klaus303" zu derselben Gruppe (z.b. "users") gehören würden, dürfte "alek202" auf die Dateien von "klaus303" zugreifen.[/u]