Jump to content
Froxlor Forum
  • 0

File-Permissions


alex

Question

Hallo miteinander,

 

Nachdem Froxlor nun erfolgreich eingerichtet ist, h?tte ich noch eine Frage. Was ich an Froxlor besonders mag, ist dass es schlank ist und nicht f?r jeden Kunden einen Benutzer auf dem System anlegt. Doch wie sieht's nun mit den File-Permissions aus? Ich habe DokuWiki installiert, und das beklagt sich regelm?ssig ?ber fehlende Rechte. Gestern hab ich noch Wikiwig ausgetestet, da dasselbe. Selbst wenn ich die Rechte in Verzeichnissen auf 777 ?ndere, k?nnen die PHP Scripts nicht rein schreiben.

K?nnte das allenfalls an Froxlor/PHP und der User-Konfiguration liegen? Selbiges Verhalten hab ich auf meinem anderen vServer (ohne Froxlor) noch nie erlebt.

 

Gr?sse,

Alex

Link to post
Share on other sites

13 answers to this question

Recommended Posts

So etwas ist immer Kunden-Sache, der kann Ordner/Dateirechte selbst via FTP anpassen. Froxlor hat damit nichts zu tun.

 

Auch welche PHP scripts wohinschreiben d?rfen h?ngt nicht unbedingt an Froxlor. ?berpr?fe die Owner/Groups des Kunden und open_basedir/safe_mode einstellungen

Link to post
Share on other sites

Okay. Wenn ich normal was via FTP hochlade, sieht das ganze so aus (Abfrage als root via ssh):

 

ls -l test

total 28

-rw-r--r-- 1 10001 10001 8357 Mar 2 22:44 changelog.txt

-rw-r--r-- 1 10001 10001 9185 Mar 2 22:44 readme.txt

-rw-r--r-- 1 10001 10001 22 Mar 2 22:44 version.txt

 

open_basedir ist in der php.ini auskommentiert.

safe_mode ist in der php.ini auf On, wobei ich ihn auch schon auf OFF hatte.

 

Sagt uns das was? Danke f?r die Hilfe!

 

EDIT: Habe den Benutzer von 10001 auf www-data gesetzt (rekursiv) und siehe da, es funktioniert. Scheint wohl doch was mit Froxlor zu tun haben? Habe zwei unterschiedliche FTP client. Egal mit welchem, es wird immer unter Benutzer 10001 hochgeladen. Und dies schien nicht zu funktionieren.

 

Alex

Link to post
Share on other sites

Okay. Wenn ich normal was via FTP hochlade, sieht das ganze so aus (Abfrage als root via ssh):

 

 

 

open_basedir ist in der php.ini auskommentiert.

safe_mode ist in der php.ini auf On, wobei ich ihn auch schon auf OFF hatte.

 

Sagt uns das was? Danke f?r die Hilfe!

 

EDIT: Habe den Benutzer von 10001 auf www-data gesetzt (rekursiv) und siehe da, es funktioniert. Scheint wohl doch was mit Froxlor zu tun haben? Habe zwei unterschiedliche FTP client. Egal mit welchem, es wird immer unter Benutzer 10001 hochgeladen. Und dies schien nicht zu funktionieren.

 

Alex

 

 

Wenn an einem Server in der Shell, in der ich arbeite, bsp. im Verzeichnis /var/customers/webs/ nach einem "ls -l" die Owner und Groupowner der Dateien kuriose, mir unbekannte IDs angezeigt werden, hatte das meistens damit zu tun, dass libnss nicht korrekt funktioniert, bzw. die DB-Verbindung des Services nicht korrekt steht. Deswegen kann der Name des Users/ der Group nicht ausgegeben werden. Die FTP-User die du/Kunden in Froxlor konfigurierst werden nicht in der /etc/passwd deines Systems eingetragen, sondern dynamisch aus der Froxlor-DB ausgelesen (z.B. Tabelle ftp_users).

 

<Distribution> ? Sonstige (System) ? libnss (system login with mysql)

 

 

In __irgendeinem__ Fall musste man statt libnss, das Paket libnss-bg o.?. installieren (auf einem Debian System war das glaub ich). Vielleicht stimmt an deinem System hier irgendetwas nicht. Bei mir zumindest funktioniert das was Froxlor an Configs bereit stellt.

 

Recherchiere eben hier im Forum, solche Themen werden ziemlich oft durch gekaut :)

Link to post
Share on other sites

Wenn an einem Server in der Shell, in der ich arbeite, bsp. im Verzeichnis /var/customers/webs/ nach einem "ls -l" die Owner und Groupowner der Dateien kuriose, mir unbekannte IDs angezeigt werden, hatte das meistens damit zu tun, dass libnss nicht korrekt funktioniert, bzw. die DB-Verbindung des Services nicht korrekt steht. Deswegen kann der Name des Users/ der Group nicht ausgegeben werden. Die FTP-User die du/Kunden in Froxlor konfigurierst werden nicht in der /etc/passwd deines Systems eingetragen, sondern dynamisch aus der Froxlor-DB ausgelesen (z.B. Tabelle ftp_users).

 

<Distribution> ? Sonstige (System) ? libnss (system login with mysql)

 

 

In __irgendeinem__ Fall musste man statt libnss, das Paket libnss-bg o.?. installieren (auf einem Debian System war das glaub ich). Vielleicht stimmt an deinem System hier irgendetwas nicht. Bei mir zumindest funktioniert das was Froxlor an Configs bereit stellt.

 

Recherchiere eben hier im Forum, solche Themen werden ziemlich oft durch gekaut :)

 

So, hab die Geschichte mit libnss gerade gebogen, hatte nur vergessen, das Paket zu installieren. Jetzt werden auch die Benutzer wunderbar angezeigt. Problem mit der Berechtigung besteht aber immer noch. PHP scheint nicht in diese Verzeichnisse schreiben zu d?rfen, obwohl die Permissions auf 777 sind und die Ownership auf www-data l?uft.

Link to post
Share on other sites
Problem mit der Berechtigung besteht aber immer noch. PHP scheint nicht in diese Verzeichnisse schreiben zu d?rfen, obwohl die Permissions auf 777 sind und die Ownership auf www-data l?uft.

 

 

Der Server generiert auch Logs oder? (/var/log/apache2/error.log & /var/customers/logs/<Kunde>-error.log)

 

 

FCGID nutzt du nicht oder?

Link to post
Share on other sites

Der Server generiert auch Logs oder? (/var/log/apache2/error.log & /var/customers/logs/<Kunde>-error.log)

 

 

FCGID nutzt du nicht oder?

 

FCGID nutze ich nicht.

 

Bez?glich Logs, ein immer wiederkehrender Eintrag in der Apache Log ist:

 

File does not exist: /var/www/images, referer: http://94.126.19.114/froxlor/admin_index.php

File does not exist: /var/www/favicon.ico

 

wobei dies auch mit dem neuen Design zusammenh?ngen k?nnte, right? Was anderes spannendes gibt's da drin nicht.

in der ErrorLog des Kunden kommt aber was interessantes!

PHP Warning: is_dir(): open_basedir restriction in effect. File(/var/lib/php5) is not within the allowed path(s)

 

Wobei ich sagen muss, dass es im Zeitraum, seit ich das Script installiert habe, keine Fehler aufgelistet sind. Der obengenannte ist noch von fr?her, aber vielleicht verschwinden damit auch die aktuellen Fehler.

 

open_basedir restriction in effect. Hmm, kann das sein, wenn ich open_basedir auskommentiert habe?

 

;open_basedir =

 

Alex

Link to post
Share on other sites

open_basedir restriction in effect. Hmm, kann das sein, wenn ich open_basedir auskommentiert habe?

 

Das ist unlogisch...Lies dir deinen Satz nochmal genau durch :)

 

So, wenn du kein FCGID nutzt, sollte zumindest die gruppe der Kunden-Docroots der Webserver-Benutzer sein, z.B. "web1:www-data", denn der Webserver ist nicht in der Gruppe des users, daher kann er nat?rlich nicht schreiben.

Da er aber bei dir auch bei 777 nicht schreiben kann scheint garantiert woanders einen Ursprung zu haben. Mit welchem Script versuchst du denn WO was zu schreiben?

Link to post
Share on other sites

Das ist unlogisch...Lies dir deinen Satz nochmal genau durch :)

 

Dann kl?r mich bitte auf. open_basedir ist auskommentiert. Folglich gar nicht aktiv, right? Deshalb macht die Fehlermeldung meiner Meinung nach auch keinen Sinn. Wenn ich komplett falsch liege, bitte ich um Aufkl?rung ;-)

 

So, wenn du kein FCGID nutzt, sollte zumindest die gruppe der Kunden-Docroots der Webserver-Benutzer sein, z.B. "web1:www-data", denn der Webserver ist nicht in der Gruppe des users, daher kann er nat?rlich nicht schreiben.

Da er aber bei dir auch bei 777 nicht schreiben kann scheint garantiert woanders einen Ursprung zu haben. Mit welchem Script versuchst du denn WO was zu schreiben?

 

Nutze wirklich kein FCGID.

Wegen der Gruppe/Benutzergeschichte: Soll ich man ein rekursives "chroot -R kundenname:www-data /pfad/zum/kundenverzeichnis" machen?

Link to post
Share on other sites

Dann kl?r mich bitte auf. open_basedir ist auskommentiert. Folglich gar nicht aktiv, right? Deshalb macht die Fehlermeldung meiner Meinung nach auch keinen Sinn. Wenn ich komplett falsch liege, bitte ich um Aufkl?rung ;-)

 

korrekt :)

 

Wegen der Gruppe/Benutzergeschichte: Soll ich man ein rekursives "chroot -R kundenname:www-data /pfad/zum/kundenverzeichnis" machen?

 

Ein versuch ist es Wert ja, denn Rechte m??ig ist das eigentlich die L?sung

Link to post
Share on other sites

korrekt :)

 

Na also, hab auch nie was anderes behauptet :-P ;-)

 

 

Ein versuch ist es Wert ja, denn Rechte m??ig ist das eigentlich die L?sung

 

Ich meinte nat?rlich 'chown' nicht chroot. Langer Tag heute... ;-)

Hab ich gemacht. Keine Ver?nderung. Reklamiert immer noch, dass das Skript das Verzeichnis nicht erstellen kann.

Link to post
Share on other sites

nopaste doch bitte mal besagtes Script...das kann ja irgendwie nicht sein

 

Nun, ist ein ganzes Wiki. DokuWiki (dokuwiki.org) um genau zu sein. Habe dort im Forum auch schon geklagt, weiss niemand weiter.

 

Interessanterweise funktionierte die erste Installation nicht - mangels Schreibrechten. Deshalb habe ich auf 777 umgestellt. Und siehe da, Installation lief problemlos ab. Nun happert es aber an der Weiterverwendung - es hagelt Fehlermeldungen, dass weder Verzeichnisse noch Dateien geschrieben werden k?nnen.

 

Lustiger Fakt noch: Habe zuvor noch ein anderes Wiki versucht, zu installieren. Es scheiterte auch an den Schreibrechten.

 

 

Alex

Link to post
Share on other sites

Dann stimmt woanders was nicht, ich habe auch zich dokuwikis unter nem Froxlor account (allerdings mit fcgid, sollte aber kein problem sein). Wenn du willst, PM mir nen zugang, dann werf' ich gerne mal einen Blick drauf, vllt h?ngts ja doch woanders

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...