☰

Der Dateibesitz im WordPress-Verzeichnis ändert sich jedes Mal nach dem Hochladen von Dateien/Plugins

tag-icon • tag-icon linux apache-2.2 permissions wordpress
Der Dateibesitz im WordPress-Verzeichnis ändert sich jedes Mal nach dem Hochladen von Dateien/Plugins

auf CentOS 7 habe ich eine WordPress-Website mit Eigentümerschaft im Stammverzeichnis erstelltWebsitename:Websitegruppeund Verzeichnisberechtigungen755, Dateiberechtigungen644standardmäßig eingestellt

Wenn sich der Entwickler beim WordPress-Dashboard anmeldet und versucht, etwas auf Medien hochzuladen oder Plugins zu installieren, meldet das WP, dass keine Schreibberechtigung vorliegt.

dann musste ich g+w Berechtigungen für das WP-Stammverzeichnis erteilen, dann konnte er Plug-ins installieren oder Medien hochladen.

nach dem Hochladen der Medien ändert sich die Berechtigung für hochgeladene Plugins/Medien zuapache:apacheausWebsitename:Websitegruppe

wie kann man das vermeiden?

  1. Ich gebe g+x-Berechtigungen für das WP-Stammverzeichnis, damit der Entwickler Plugins installieren/Medien hochladen kann
  2. und der Besitz eines Uploads vom WP-Dashboard sollte nicht in apache:apache geändert werden.

was ich versucht habe

Derzeit habe ich keine Alternative gefunden, um dies zu stoppen. Jedes Mal musste ich G+W-Berechtigungen erteilen und sie nach der Entwicklerarbeit wieder rückgängig machen.

Antwort1

Der Webserver (oder der PHP-Prozess, je nach Konfiguration) benötigt Schreibzugriff auf das Verzeichnis. Die einzige praktikable Möglichkeit besteht darin, den Prozess als Benutzer auszuführen websitename.

Eine weitere Möglichkeit wäre grundsätzlich, dem Benutzer apacheSchreibrechte über ACL oder durch Hinzufügen zur websitegroupGruppe zu erteilen. Dies würde jedoch auch dazu führen, dass die hochgeladenen Dateien Eigentum von sind apache. Wenn Sie möchten, dass alle Dateien und Ordner Eigentum von sind, websitenamemüssen Sie den Webserver als dieser Benutzer ausführen.

Antwort2

Ihre Beschreibung, wie dies bereitgestellt wird, ist nicht hilfreich. Beginnen wir von vorne.

Benutzer:

  • apache - die UID, unter der Ihre PHP-Laufzeit ausgeführt wird
  • dev1, dev2, dev2 - Entwickler
  • Backup - zum Erstellen von Backups der Site
  • Support[n] – zur Untersuchung von Problemen

Aufgrund der Konzeption von Wordpress ist die Bedienung sehr schwierig, es sei denn, „Apache“ hat vollständigen Lese-/Schreibzugriff auf die Site.

Wenn die gesamte Verwaltung über die Web-Benutzeroberfläche erfolgt, müssen die EntwicklerbeliebigZugriff auf die Dateien im Dokumentstamm. Ich habe jedoch Websites gesehen, auf denen Entwickler routinemäßig CLI-Zugriff auf aktualisierte Dateien verwenden. Nehmen wir also an, dass sie Lese-/Schreibzugriff benötigen.

Backup-UIDs benötigen nur Lesezugriff auf die Dateien.

Der Support benötigt nur Lesezugriff auf die Dateien.

Bleibt nur noch der Site-Benutzer. Dies ist Ihr Konstrukt. In Ermangelung weiterer Informationen darüber, wie Sie es verwenden, scheint es völlig überflüssig zu sein.

Die einzigen Zugriffsklassen sind also Lesen+Schreiben und Nur-Lesen. Aber nur aus Spaß sagen wir, es gäbe eine zusätzliche Klasse ohne Zugriff – und nennen diesen Benutzer „Alien“.

Der Benutzerbesitz wird immer durch die UID bestimmt, die eine Datei erstellt – und ist pro Benutzer eindeutig. Wir können dies also nicht als Mechanismus zum Gewähren des Zugriffs verwenden.

Benutzer können jedoch mehreren Gruppen angehören und jede Gruppe kann mehrere Benutzer haben. Daher können wir das Lese-/Schreibrecht einer bestimmten Gruppe zuordnen. Nennen wir sie „webupdate“.

Bleib nur der Lesezugriff (Backup und Support) – der über die „anderen“ Berechtigungsbits bereitgestellt werden kann.

Aber wie schließt man dann "Alien" aus? Indem man die Site in ein Verzeichnis stellt, auf das Alien keinen Zugriff hat - das heißt, wir brauchen eine andere Gruppe, die Leute identifiziert, diemancheZugriff. Nennen Sie dies Webzugriff.

Also die Gruppenmitgliedschaft:

  • Webupdate: Apache, dev1, dev2...devn
  • Webzugriff: Apache, dev1, dev2...devn, Backup, Support[n]

dann haben wir die Verzeichnisse, Berechtigungen und Eigentümer:

drwxr-x--- root:webaccess /var/www/SITENAME
drwxrwxr-x ????:webupdate /var/www/SITENAME/html  (document root)

Alles schön und gut, aber wenn jemand in „webupdate“ eine neue Datei oder ein neues Verzeichnis im Dokumentstamm erstellt, ist die Gruppeneigentümerschaft seine STANDARD-Gruppe – nicht webupdate. Sie können dieses Verhalten mit dem Setgid-Bit in Verzeichnissen ändern:

drwxrwSr-x ????:webupdate /var/www/SITENAME/html

Der letzte Teil des Puzzles besteht darin, sicherzustellen, dass die Umask für Mitglieder von Webupdate auf 00x eingestellt ist, damit neue Dateien und Verzeichnisse die richtigen Berechtigungen erhalten. Vergessen Sie nicht, dies in Ihrer sshd_config für den SFTP-Server sowie für interaktive Shells festzulegen.

Sobald Sie die Gruppen eingerichtet haben, können Sie Folgendes ausführen:

chown -R apache:webupdate  /var/www/SITENAME/html
chmod -r g+s /var/www/SITENAME/html

Und das war’s – Sie müssen die Berechtigungen nie wieder korrigieren.

verwandte Informationen