Wie richte ich Linux-Berechtigungen für den WWW-Ordner ein?

Lösung 1:

Nach mehr Recherche scheint es eine andere (möglicherweise bessere Möglichkeit) zu sein, dies zu beantworten, indem man den www-Ordner so einrichtet.

1. sudo usermod -a -G developer user1 (Jeden Benutzer zur Entwicklergruppe hinzufügen)
2. sudo chgrp -R developer /var/www/site.com/ damit Entwickler darin arbeiten können
3. sudo chmod -R 2774 /var/www/site.com/ damit nur Entwickler Dateien erstellen/bearbeiten können (Andere/Welt kann lesen)
4. sudo chgrp -R www-data /var/www/site.com/uploads damit www-data (apache/nginx) Uploads erstellen kann.

Seit git läuft, wie der Benutzer es aufruft, dann sollte der Benutzer, solange er in der Gruppe "Entwickler" ist, in der Lage sein, Ordner zu erstellen, PHP-Dateien zu bearbeiten und das Git-Repository zu verwalten.

Hinweis:In Schritt (3):„2“ in 2774 bedeutet „Gruppen-ID festlegen“ für das Verzeichnis. Dadurch erben darin neu erstellte Dateien und Unterverzeichnisse die Gruppen-ID des übergeordneten Verzeichnisses (anstelle der primären Gruppe des Benutzers) Referenz:http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

Lösung 2:

Ich bin mir nicht sicher, ob es "richtig" ist, aber ich mache Folgendes auf meinem Server:

• /var/www enthält einen Ordner für jede Website.
• Jede Website hat einen bestimmten Eigentümer, der als Eigentümer aller Dateien und Ordner im Verzeichnis der Website festgelegt ist.
• Alle Benutzer, die die Website pflegen, werden in einer Gruppe für die Website zusammengefasst.
• Diese Gruppe wird als Gruppeneigentümer aller Dateien und Ordner im Verzeichnis festgelegt.
• Alle Dateien oder Ordner, die vom Webserver geschrieben werden müssen (z. B. PHP), haben ihren Besitzer auf www-data geändert, den Benutzer, unter dem Apache läuft.

Denken Sie daran, dass Sie das Ausführungsbit für Verzeichnisse aktiviert haben sollten, damit Sie den Inhalt auflisten können.

Lösung 3:

Nach weiteren Recherchen scheint es, dass git/svn TOOLS sind KEIN Problem, da sie als der Benutzer ausgeführt werden, der sie verwendet. (Die git/svn-Daemons sind jedoch eine andere Sache!) Alles, was ich mit git erstellt/geklont habe, hatte meine Berechtigungen und das git-Tool wurde in /usr/bin aufgeführt was zu dieser These passt.

Git-Berechtigungen gelöst.

Benutzerberechtigungen scheinen lösbar zu sein, indem alle Benutzer, die Zugriff auf das www-Verzeichnis benötigen, zum www-data hinzugefügt werden Gruppe, unter der Apache (und Nginx) ausgeführt werden.

Es scheint also diese eine Antwort zu sein zu dieser Frage geht so:

Standardmäßig /var/www gehört root:root und niemand dort Dateien hinzufügen oder ändern können.

1) Gruppenbesitzer ändern

Zuerst müssen wir die www-Verzeichnisgruppe so ändern, dass sie der „www-data“ statt der „root“-Gruppe gehört

sudo chgrp -R www-data /var/www

2) Benutzer zu www-data hinzufügen

Dann müssen wir den aktuellen Benutzer (und alle anderen) zur www-data-Gruppe

hinzufügen

sudo usermod -a -G www-data demousername

3) CHMOD-www-Verzeichnis

Ändern Sie die Berechtigungen so, dass NUR der Besitzer (root) und alle Benutzer in der Gruppe "www-data" Dateien und Verzeichnisse rwx (lesen/schreiben/ausführen) können (niemand sonst sollte überhaupt darauf zugreifen können ).

sudo chmod -R 2770 /var/www

Jetzt sind alle Dateien und Verzeichnisse, die von jedem Benutzer erstellt wurden, der Zugriff hat (d. h. in der Gruppe „www-data“), für Apache und damit für PHP lesbar/schreibbar.

Ist das richtig? Was ist mit Dateien, die PHP/Ruby erstellt - können die www-data-Benutzer darauf zugreifen?

Lösung 4:

Klebrigkeit ist keine Vererbung von Berechtigungen. Stickiness in einem Verzeichnis bedeutet, dass nur der Besitzer einer Datei oder der Verzeichnisbesitzer diese Datei im Verzeichnis umbenennen oder löschen kann, obwohl die Berechtigungen etwas anderes sagen. Also 1777 auf /tmp/.

Im klassischen Unix gibt es keine Berechtigungsvererbung basierend auf dem Dateisystem, sondern nur auf der umask des aktuellen Prozesses. Auf *BSD oder Linux mit setgid im Verzeichnis wird das Gruppenfeld neu erstellter Dateien auf das gleiche wie das des übergeordneten Verzeichnisses gesetzt. Für alles andere müssen Sie sich die ACLs ansehen, mit der „Standard“-ACL für Verzeichnisse, die Ihnen geerbte Berechtigungen ermöglichen.

Sie sollten damit beginnen, Folgendes zu definieren:* welche Benutzer Zugriff auf das System haben* was Ihr Bedrohungsmodell ist

Wenn Sie beispielsweise Webhosting mit mehreren Kunden betreiben und nicht möchten, dass sie die Dateien der anderen sehen, können Sie für alle diese Benutzer eine gemeinsame Gruppe "webcusts" und einen Verzeichnismodus von 0705 verwenden. Dann Dateien, die von bereitgestellt werden der Webserver-Prozess (nicht in "webcusts") werden die anderen Perms sehen und zugelassen werden; Kunden können die Dateien der anderen nicht sehen und die Benutzer können mit ihren eigenen Dateien herumspielen. Dies bedeutet jedoch, dass Sie in dem Moment, in dem Sie CGI oder PHP zulassen, verfügen um sicherzustellen, dass die Prozesse als der bestimmte Benutzer ausgeführt werden (gute Praxis, für mehrere Benutzer auf einem Host, für die Verantwortlichkeit). Anderenfalls könnten Kunden mit den Dateien der anderen herumspielen, indem sie dies einem CGI überlassen.

Wenn der Laufzeitbenutzer einer Website jedoch derselbe ist wie der Eigentümer der Website, dann haben Sie Probleme damit, Inhalte im Falle einer Sicherheitslücke im Skript nicht vor Missbrauchern schützen zu können. Hier gewinnen dedizierte Hosts, sodass Sie einen Laufzeitbenutzer haben können, der sich vom statischen Inhaltseigentümer unterscheidet, und sich nicht so sehr um die Interaktion mit anderen Benutzern kümmern müssen.

Lösung 5:

Ich glaube, dass der beste Weg, dies zu tun, die Verwendung von Posix-ACLs ist. Sie sind bequem zu handhaben und bieten alle Funktionen, die Sie benötigen.

http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs