Dateirechte im Produktivmodus ?!?!

Community Germany
1

Hallo Leute,

ich installiere die aktuelle Version von NEOS und bekomme öfter Rechteprobleme, weil z.B. Caches nach CLI Befehlen nicht mehr beschrieben werden können.
Wenn ich dann nach den Fehlermeldungen die entsprechende Verzeichnisse prüfe, haben diese statt der vorgegebenen Rechte user:www-data wieder www-data:www-data gesetzt.

Ich habe den Apachen auch auf user:www-data gesetzt, identisches Problem.

Irgendwas setzt den Besitzer immer wieder auf www-data:www-data …

Wenn ich selbst alles auf www-data:www-data setze, kann ich ja im CLI nicht mehr mit dem Benutzer user arbeiten und muss alles mit Root bearbeiten, was ja auch nicht Sinn der Sache sein soll.

Wenn ich den Befehl

 sudo ./flow core:setfilepermissions user www-data www-data

absetze, funktioniert alles wieder bis nach irgendeinem anderen CLI Befehl und da der obige Befehl etwas dauert, macht es keinen wirklichen Spaß.

Der Benutzer “user” ist ebenfalls in der Gruppe “www-data”, daher verstehe ich das Problem nicht.

Wo ist da der Fehler ??

Grüße
Net

2

Hi,

hast du PHP als FPM laufen und im Pool einen anderen User?

3

Also ich habe PHP 8.2 im FPM Modus laufen (ist ja seit 8.0 Standard) und mein normaler User ist auch in der Gruppe www-data.
Dieser User ist im oben genannten Befehl der genannte “user”.
Oder meinst Du was anderes mit Pool ??

4

Die Apache-User-Einstellungen sind im Fall PHP als FPM weitestgehend irrelevant (spielt dann nur noch eine Rolle für das Web/Resources Verzeichnis).

Wichtig dann ist vor allem die Pool-Definition des verwendeten FPM-Pools. Dort sollte als Benutzer und Gruppe in deinem Fall dann www-data eingetragen sein.

https://www.php.net/manual/de/install.fpm.configuration.php#user

1 Like
5

Hallo Ferdinant, www-data ist eingetragen, sowohl als User, als such als Gruppe.

Der Cache wird ja auch mit www-data:www-data geschrieben, ./flow Befehle funktionieren dann aber nicht mehr (Rechtefehlermeldung).

"chown"e ich die Dateien und Verzeichnisse wieder auf user:www-data, dann geht wieder alles bis zum nächsten ./flow Befehl.

6

Ich glaube der einfachste Weg ist, wenn Dein user als primäre Gruppe “www-data” hat.

7

Hallo Christian,
das Problem liegt scheinbar nicht beim User.
Denn dieses Problem taucht immer nach einem ./flow Befehl auf oder besser gesagt, wenn der Cache geändert wurde.
Hier wird das Cache Verzeichnis von user:www-data auf www-data:www-data gesetzt, was dann wiederum weitere Rechteprobleme verursacht.
Setze ich die Rechte per

sudo ./flow core:setfilepermissions user www-data www-data

wieder zurück, funktioniert alles wieder, bis halt wieder irgendein ./flow Befehl ausgeführt wird, der den Cache ändert …

8

Das grundlegende Prinzip hier ist ja folgendes:

  • “Der User” und “der Webserver” sind in derselben Gruppe.
  • Die Verzeichnisse und Dateien sind für die Gruppe schreibbar.
  • Daher ist egal, wer von beiden ein Verzeichnis bzw. eine Datei besitzt.

Was hier bisher nicht erkennbar ist: Welche Rechte haben die Verzeichnisse/Dateien denn, wenn es geht – und welche, wenn nicht? Achtung, evtl. sind die “klassischen” Unix-Rechte (“ugo-rwx”) hier nicht relevant, falls ACL aktiv sind. Das sieht man am Outpout von setfilepermissions (trying to set ACLs via … bzw. Access Control Lists seem not to be supported by your system).

9

Hallo Karsten,
vielen Dank für Deine Infos.

Der User und der Webserver sind in der selben Gruppe, bzw. der User ist auch in der Gruppe des Webservers.
Die Verzeichnisse und Dateien sind beschreibbar, alles funktioniert auch ohne Rootrechte.

Das Problem ist, dass immer (verm.) nur eine Datei im Cacheverzeichnis nach einem FLOW Befehl von user:www-data auf www-data:www-data gesetzt wird, was ja auch egal wäre aber weitere FLOW Befehle werden dann verweigert mit der Meldung, dass der Cache nicht beschrieben werden konnte.

Führe ich den oben genannten Befehl aus

sudo ./flow core:setfilepermissions user www-data www-data

geht wieder alles genau bis zum nächsten FLOW Befehl und der setfilepermissions Befehl dauert auch immer ewig, funktioniert aber.

Hier mal das Ergebnis aus einem Cache Flush:

user@test:/var/www/test.domain.tld$ FLOW_CONTEXT=Production ./flow flow:cache:flush
The cache file "/var/www/test.domain.tld/Data/Temporary/Production/Cache/Data/Flow_Object_Configuration/objects" could not be written.

  Type: Neos\Cache\Exception
  Code: 1334756737
  File: Packages/Libraries/neos/cache/Classes/Backend/SimpleFileBackend.php
  Line: 169
user@test:/var/www/test.domain.tld$

Schaue ich mir nun das Cache Verzeichnis an, sind die Rechte so:

Alle Verzeichnisse inkl. /Flow_Object_Configuration/ haben user:www-data, nur die bemängelte Datei /objects ist dann plötzlich www-data:www-data.

Setze ich dann wieder alles mit dem setfilepermissions zurück, geht auch die Datei wieder zu beschreiben.

Was setzt die bemängelte Datei auf www-data:www-data zurück und warum ist das ein Problem, wenn der Webserver und der SSH User in der selben Gruppe sind ??

Grüße
Net

10

Wo sehe ich denn den Output ??
Der Befehl selbst gibt ja so nix aus oder muss ich da in irgend ein Logfile ??

Gruß
Net

11

So, was mir jetzt auch noch aufgefallen ist:
Den Cache Befehl kann ich mehrmals hintereinander ausführen aber wenn ich z.B. auch einen composer Befehl ausführe, ist wieder Essig …
Und zwar wieder mit der gleichen Datei (objects).

Es scheint auch nur diese eine Datei betroffen zu sein.

12

Öhm, nicht? :roll_eyes: Ja,in der Tat, wenn man das über flow … aufruft, wird das unterdrückt. :see_no_evil:

Versuch mal sudo Packages/Framework/Neos.Flow/Scripts/setfilepermissions.sh user www-data www-data direkt.

Und gib doch mal die Ausgabe von ls -l /var/www/test.domain.tld/Data/Temporary/Production/Cache/Data/Flow_Object_Configuration/objects hier an für die beiden Fälle (geht/geht nicht).

13

Der erste Teil:

user@test:/var/www/test.domain.tld$ sudo Packages/Framework/Neos.Flow/Scripts/setfilepermissions.sh user www-data www-data
Neos Flow File Permission Script

Checking permissions from here upwards.
Making sure Data and Web/_Resources exist.
Setting file permissions, trying to set ACLs via chmod ...
Setting file permissions, trying to set ACLs via setfacl ...

Note: Access Control Lists seem not to be supported by your system.

Setting file permissions per file, this might take a while ...
User is a member of the webserver group www-data, continuing
Done.

Was mich da stutzige macht:

Note: Access Control Lists seem not to be supported by your system.

Ist das der Grund oder kann man das ignorieren ??

Nachtrag:
Das war der Grund, ACL hat gefehlt.
Nachinstalliert und alles geht, Danke.
Den zweiten Teil habe ich daher wieder gelöscht.

16

Habe jetzt ACL nachinstalliert:

Checking permissions from here upwards.
Making sure Data and Web/_Resources exist.
Setting file permissions, trying to set ACLs via chmod ...
Setting file permissions, trying to set ACLs via setfacl ...
Done.

Das ging auch recht schnell.

17

Problem gelöst !!

Danke für Deine (und Eure) Hilfe.

Es lag am fehlenden ACL.

Jetzt ist “objects” zwar immer noch www-data:www-data (warum auch immer nur diese eine Datei, auch wenn User und Webserver in gleicher Gruppe nicht bearbeitbar waren) aber der Cachefehler ist nun weg und ich muss nicht nach jedem FLOW Befehl die Rechte neu konfigurieren.

Danke und viele Grüße
Net

18

@kdambekalns heißt dass das wir unseren acl fallback löschen können und acl prinzipiell erzwingen müssen? (Über das setup als Check)

19

Keine Ahnung. Wir wissen leider noch immer nicht, welche Rechte die objects-Datei hatte (und ggf. das/die Verzeichnisse “darüber”), wenn es (nicht) ging. @NetSecond – falls du das nochmal herausfinden könntest, das wäre großartig. Denn bei korrektem Ownership-Setup kann eigentlich nur das Schreibrecht für die Gruppe fehlen…

Wegen Output: BUG: `flow:core:setfilpermissions` supresses script output · Issue #3136 · neos/flow-development-collection · GitHub

20

@kdambekalns
So, ich habe noch eben schnell eine zusätzliche Instanz von NEOS parallel ohne ACL installiert, da auf der originalen der Fehler nicht mehr provozierbar war.

Jetzt habe ich den Cache Fehler wieder und Der Befehl

ls -l /var/www/test.domain.tld/Data/Temporary/Production/Cache/Data/Flow_Object_Configuration/objects

bringt MIT Fehler folgende Ausgabe:

-rw-r--r-- 1 www-data www-data 254487 17. Aug 15:53 /var/www/test.domain.tld/Data/Temporary/Production/Cache/Data/Flow_Object_Configuration/objects

Installiere ich jetzt ACL nach und starte erneut setfilepermissions per

sudo Packages/Framework/Neos.Flow/Scripts/setfilepermissions.sh user www-data www-data

sieht das dann so aus:

-rw-rw----+ 1 www-data www-data 254487 17. Aug 14:54 /var/www/test.domain.tld/Data/Temporary/Production/Cache/Data/Flow_Object_Configuration/objects

Geht Nicht / geht:

-rw-r--r-- 1 www-data www-data 254487 geht NICHT
-rw-rw----+ 1 www-data www-data 254487 GEHT

Ich hoffe, ich konnte helfen.

Grüße
Net

21

Vielen Dank, das hilft. Es fehlt also das w-Bit für die Gruppe, das müsste eigentlich gesetzt sein/bleiben/werden. :thinking:

(Dass es mit ACL geht, liegt daran, dass dort die Rechte nicht mehr in rwx stecken, sondern hinter dem + versteckt sind. Das w spiegelt das nur so halb wieder.)

22

Es scheint, als ob das Problem mit den Dateiberechtigungen im Cacheverzeichnis zusammenhängt und insbesondere nach der Ausführung von FLOW-Befehlen auftritt. Obwohl der Befehl sudo ./flow core:setfilepermissions vorübergehend Abhilfe schafft, ist dies keine nachhaltige Lösung.

Eine mögliche Ursache könnte sein, dass die Dateien und Verzeichnisse im Cacheverzeichnis unterschiedliche Besitzer haben, nachdem bestimmte FLOW-Befehle ausgeführt wurden. Dies könnte zu Konflikten führen.

Um das Problem zu beheben, könntest du sicherstellen, dass alle Dateien und Verzeichnisse im Cacheverzeichnis einheitliche Besitzer und Gruppen haben. Du könntest dies erreichen, indem du einen Befehl ähnlich dem folgenden ausführst:

bashCopy code

sudo chown -R user:www-data /path/to/cache/directory

Hierbei sollte /path/to/cache/directory durch den tatsächlichen Pfad zu deinem Cacheverzeichnis ersetzt werden. Dieser Befehl setzt den Besitzer und die Gruppe für alle Dateien und Unterverzeichnisse im Cacheverzeichnis auf user und www-data.

Nach dem Ausführen dieses Befehls solltest du versuchen, FLOW-Befehle erneut auszuführen und prüfen, ob das Problem weiterhin besteht. Falls das Problem weiterhin besteht, könnte es auch sinnvoll sein, die genauen Berechtigungen und Besitzer von Dateien und Verzeichnissen nach einem FLOW-Befehl zu überprüfen, um mögliche Abweichungen zu identifizieren. Klicken Sie hier für weitere Informationen