[Debian 9][Apache 2] Permissions Probleme

[tmuecksch 0]

Guten Tag,

ich habe einen Debian 9 Server mit Froxlor und Apache2 am laufen. Wenn ich mit dem Kunden FTP Zugang Dateien hochlade haben diese Ordnungsgemäß das ownership 10000:10000.

Wenn jedoch in der PHP-Weboberfläche eine Datei hochgeladen wird, wird diese mit dem ownership www-data:www-data hochgeladen. Liegt hier ein Konfigurationsfehler vor oder ist das Verhalten sogar so gewünscht? Ich kann den Fehler leider nicht entdecken. Das Problem ist nur, dass das PHP-Script dann eine Permission Denied Fehlermeldung wirft, wenn versucht wird die Datei zu lesen.

 

Liebe Grüße
tmuecksch

[d00p 140]

--w--w--w- ist ja Quatsch.... Schreiben aber nicht lesen? Deine umask ist wohl kaputt

[d00p 140]

Ja das die Dateien von www-data angelegt werden wenn du was hochlädst via http und mod_php nutzt ist das klar...aber BERECHTIGUNGEN sollten passen, denn der User www-data wird als gruppenmitglied des Kunden-Users hinzugefügt, der sollte also da ran dürfen

[tmuecksch 0]

Falls noch einmal jemand ein solches Problem mit Wordpress haben sollte hier meine Lösung:

Unter https://gist.github.com/Adirael/3383404 gibt es ein script welches die Permissions für Wordpress Installationen fixt. Anschließend werden die Dateien wieder korrekt angelegt. Bitte unbedingt die Kommentare lesen, da sind wichtige Infos dabei.

[d00p 140]

Du nutzt wohl mod_php, dabei sollte aber eigentlich der Webserver User (www-data) in der Gruppe des Users sein, damit er auch die Daten ändern kann. Hast du libnss-mysql/extrausers installiert und konfiguriert?

[tmuecksch 0]

Danke für Deine Antwort!

Hier zunächst mal zu Einfachheit meine via apt-get installierten Pakete, sofern das für Dich interessant ist: https://pastebin.com/ExwSc9HY 
Hier noch meine aktivierten Apache mods: https://pastebin.com/fQagdrxG

Weder bei libnss-mysql noch bei extrausers klingelt es bei mir.

Der Server ist erst vor kurzem installiert worden, dazu habe ich ein reines Debian Image genutzt und dann Froxlor gemäß der Anleitung im Wiki und gemäß der Anweisungen in der Admin-UI unter Konfigurationen installiert. Das Einzige was ich darüber hinaus noch gemacht habe ist php-memcache zu installieren, da unser Wordpress ohne nicht funktioniert hat.

 

[d00p 140]

Dann installiere und konfiguriere libnss-extrausers wie in den Konfigurations Templates und aktiviere die Einstellung "nutze libnss-extrausers" in den Einstellungen. Dann sollte das Problem mit den Berechtigungen eigentlich behoben sein

[tmuecksch 0]

Gelöscht, da ich was übersehen habe...

 

 

[tmuecksch 0]

12 minutes ago, d00p said:

aber BERECHTIGUNGEN sollten passen, denn der User www-data wird als gruppenmitglied des Kunden-Users hinzugefügt, der sollte also da ran dürfen

Trotz installation und Aktivierung in den Einstellungen bleibt das Permissions problem.

Ich habe mal einen Screenshot einer hochgeladenen Datei beigefügt. Sie wird mit "--w--w--w- 1 www-data    www-data" erstellt... 

[tmuecksch 0]

Danke für den Hinweis, das Stichwort umask hat mir gefehlt.

sudo -u www-data touch foo

erstellt Daten mit korrekten Rechten (-rw-r--r--).

Laut diversen Google-Ergebnissen soll es helfen in "/etc/apache2/envvars" eine umask option "umask 002" einzufügen (+ apache2 Neustart versteht sich). Auch das hilft leider nicht. Ich google mal weiter...

[Neutrino 0]

vor 1 Minute schrieb tmuecksch:

umask 002

probier mal 022

[tmuecksch 0]

@Neutrino Danke für den Tipp. Auch das zeigt leider keine Wirkung.

Mittlerweile bin ich auch noch mal einen Schritt weiter. Ich habe mit folgendem Script mal getestet wie von PHP Dateien angelegt werden:

<?php
if ($fp = fopen(time() . '.txt', 'w')) {
  fwrite($fp, 'This is a simple test.');
  fclose($fp);
  echo "done";
} else {
  echo "error - cannot create file";
}

Quelle: https://serverfault.com/questions/383734/how-do-i-set-default-umask-in-apache-on-debian

Und mit diesem Script werden die Dateien korrekt angelegt. Das heißt, es muss ein Wordpress-Problem und kein Konfigurationsld00problem sein.

 

@d00p Vielen dank für's in die Richtige Richtung schubsen.

[s20 0]

Hallo,

 

ich stehe genau vor dem gleichen Problem. Die Ordner der Kunden sind mit userid 10000 angelegt. Die Namen der Kunden werden dank libnss-extrausers übersetzt. ich verwende mod_php und apache mit user www-data. Leider lässt der Webserver mich keine Dateien in diese Ordnerstruktur hochladen. Ändere ich die rechte auf www-data:www-data klappt alles. 

Das Testscript oben zeigt wie zu erwarten: "error - cannot create file"

Was mache ich denn hier falsch?

 

Danke

[d00p 140]

44 minutes ago, s20 said:

Hallo,

 

ich stehe genau vor dem gleichen Problem. Die Ordner der Kunden sind mit userid 10000 angelegt. Die Namen der Kunden werden dank libnss-extrausers übersetzt. ich verwende mod_php und apache mit user www-data. Leider lässt der Webserver mich keine Dateien in diese Ordnerstruktur hochladen. Ändere ich die rechte auf www-data:www-data klappt alles. 

Das Testscript oben zeigt wie zu erwarten: "error - cannot create file"

Was mache ich denn hier falsch?

 

Danke

dann ist der user www-data vllt nicht in der gruppe des kunden? Was sagt denn

id

id www-data

und 

id [username-des-kunden]

Dazu bitte ein ls -la des Kunden-Homedirs und evtl. Fehlermeldungen aus der apache log oder sys log

[s20 0]

Hier die Infos.

 

id www-data

uid=33(www-data) gid=33(www-data) groups=10000(KUNDE),10001(KUNDE2),33(www-data)
 

id KUNDE

uid=10000(KUNDE) gid=10000(KUNDE) groups=10000(KUNDE)
 

ls -la /var/customers/webs/KUNDE/KUNDE.de
total 240
drwxr-xr-x  7 KUNDE KUNDE  4096 Jul 16 16:51 .
drwxr-xr-x 15 KUNDE KUNDE  4096 Jul 16 16:39 ..
-rw-r--r--  1 KUNDE KUNDE   817 Jul 16 14:42 .htaccess
-rw-r--r--  1 KUNDE KUNDE   420 Mar  5 13:25 index.php
 

[d00p 140]

Just now, s20 said:

uid=33(www-data) gid=33(www-data) groups=10000(KUNDE),10001(KUNDE2),33(www-da

joa, ist aber in der gruppe....aber deine permissions sagen: nur der owner darf schreiben, nicht die group.... (rwx <> r-x)

[s20 0]

Danke für deine Hilfe, du hast vollkommen Recht.

 

find /var/customers/webs/KUNDE/ -type d -exec chmod 775 {} \;

 

bringt Abhilfe.