Frage Wie konfiguriere ich Linux-Berechtigungen für den WWW-Ordner?


Aktualisierte Zusammenfassung

Das Verzeichnis / var / www gehört root:root was bedeutet, dass niemand es benutzen kann und es völlig nutzlos ist. Da wir alle einen Webserver haben wollen, der tatsächlich funktioniert (und niemand sollte sich als "root" anmelden), müssen wir das beheben.

Nur zwei Entitäten benötigen Zugriff.

  1. PHP / Perl / Ruby / Python Alle benötigen Zugriff auf die Ordner und Dateien, da sie viele von ihnen erstellen (d. h. /uploads/). Diese Skriptsprachen sollten unter Nginx oder Apache laufen (oder auch etwas wie FastCGI für PHP).

  2. Die Entwickler

Wie bekommen sie Zugang? ich weiß das irgendwer irgendwo hat das schon mal gemacht. Mit den vielen Milliarden von Websites, die es gibt, könnte man meinen, dass es mehr Informationen zu diesem Thema geben würde.


Ich weiß, dass 777 volle Lese- / Schreib- / Ausführungs-Erlaubnis für Eigentümer / Gruppe / andere ist. Das scheint also nicht zu sein erforderlich Korrekt, da es zufällige Benutzer vollständige Berechtigungen gibt.

Welche Berechtigungen müssen verwendet werden? /var/www damit:

  1. Versionskontrolle wie git oder svn
  2. Benutzer in einer Gruppe wie "Websites" (oder sogar zu "www-data" hinzugefügt)
  3. Server wie Apache oder Lighthttpd
  4. Und PHP / Perl / Ruby

Können alle Dateien (und Verzeichnisse) dort lesen, erstellen und ausführen?

Wenn ich richtig liege, werden Rubin- und PHP-Skripte nicht direkt "ausgeführt", sondern an einen Interpreter übergeben. Es besteht also keine Notwendigkeit für die Ausführung von Berechtigungen für Dateien in /var/www...? Daher scheint es, als ob die richtige Erlaubnis wäre chmod -R 1660 was würde machen

  1. alle Dateien, die von diesen vier Entitäten gemeinsam genutzt werden können
  2. alle Dateien aus Versehen nicht ausführbar
  3. Blockieren Sie alle anderen aus dem Verzeichnis vollständig
  4. Setzen Sie den Berechtigungsmodus für alle zukünftigen Dateien auf "sticky"

Ist das richtig?

Update 1: Ich habe gerade festgestellt, dass Dateien und Verzeichnisse möglicherweise andere Berechtigungen benötigen - ich sprach über Dateien oben, so dass ich nicht sicher bin, was die Verzeichnisberechtigungen sein müssten.

Update 2: Die Ordnerstruktur von /var/www ändert sich drastisch, da eine der vier oben genannten Entitäten Ordner und Unterordner immer um viele Ebenen erweitert (und manchmal entfernt). Sie erstellen und entfernen auch Dateien, auf die die anderen drei Entitäten Lese- / Schreibzugriff benötigen. Daher müssen die Berechtigungen die oben genannten vier Dinge sowohl für Dateien als auch für Verzeichnisse erfüllen. Da keiner von ihnen eine Ausführungsberechtigung benötigt (siehe Frage zu ruby ​​/ php oben) würde ich das annehmen rw-rw-r-- Erlaubnis wäre alles was benötigt wird und absolut sicher, da diese vier Entitäten ausgeführt werden vertrauenswürdiges Personal (siehe # 2) und alle anderen Benutzer auf dem System haben nur Lesezugriff.

Update 3: Dies ist für persönliche Entwicklungsmaschinen und private Firmenserver. Keine zufälligen "Web-Kunden" mögen einen geteilten Host.

Update 4:  Dieser Beitrag von slicehost scheint die beste Erklärung zu sein, was benötigt wird, um Berechtigungen für Ihren www-Ordner einzurichten. Ich bin mir jedoch nicht sicher, welcher Benutzer oder welche Gruppe apache / nginx mit PHP ODER svn / git ausführt und wie man sie ändert.

Update 5: Ich habe (denke ich) endlich einen Weg gefunden, das alles zum Laufen zu bringen (Antwort unten). Ich weiß jedoch nicht, ob dies der richtige und sichere Weg ist, dies zu tun. Deshalb habe ich ein Kopfgeld begonnen. Die Person, die die beste Methode zum Sichern und Verwalten des www-Verzeichnisses hat, gewinnt.


61
2018-03-22 01:21


Ursprung




Antworten:


Nach mehr Nachforschungen scheint es, als ob ein anderer (möglicherweise besserer Weg) dies zu beantworten wäre, den www-Ordner so einzurichten.

  1. sudo usermod -a -G developer user1 (Fügen Sie jeden Benutzer zur Entwicklergruppe hinzu)
  2. sudo chgrp -R developer /var/www/site.com/ damit Entwickler dort arbeiten können
  3. sudo chmod -R 2774 /var/www/site.com/ so dass nur Entwickler Dateien erstellen / bearbeiten können (andere / Welt kann lesen)
  4. sudo chgrp -R www-data /var/www/site.com/uploads so dass www-data (apache / nginx) kann uploads erstellen.

Schon seit git Läuft wie jeder Benutzer es aufruft, solange der Benutzer sich in der Gruppe "Entwickler" befindet, sollte er 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 'Gruppe ID' für das Verzeichnis festlegen. Dies führt dazu, dass neue Dateien und Unterverzeichnisse, die darin erstellt werden, die Gruppen-ID des übergeordneten Verzeichnisses erben (anstelle der primären Gruppe des Benutzers). Referenz: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories 


47
2018-03-25 21:27



Sieht vernünftig für mich aus. - wazoox
Gut. Vielleicht, wenn ich das mit ein paar mehr Leuten bestätigen kann, werde ich diesen Ansatz verwenden. Es scheint die beste Antwort zu sein, die ich aus Menschen herauspressen konnte. - Xeoncross
Sie geben nicht an, wer der Eigentümer der Dateien sein würde. Würdest du es als root belassen? Dann können nur Sudoers Ihren Upload-Ordner bearbeiten (wahrscheinlich nicht das, was Sie vorhaben). - Nic
Ja, root würde der Eigentümer bleiben. Da der Gruppenbesitzer jedoch jetzt "Entwickler" ist (und wrx-Berechtigung hat), könnten auch alle Entwickler (und Apache / nginx) lesen. Keine Notwendigkeit für Sudo. - Xeoncross
Eine weitere Sache, auf die Sie achten müssen, ist Umask. Viele Systeme haben eine Standard-Umask von 022, die Schreibrechte sowohl für die Gruppe als auch für die Öffentlichkeit bei neuen Dateien löscht. Ich vermute, du willst 002 (kein Schreiben für die Öffentlichkeit) oder 007 (kein Zugang für die Öffentlichkeit). Sie können die Umask in der Apache-Konfiguration und / oder den Startskripten für jeden Prozess festlegen, der Zugriff auf das Verzeichnis benötigt. Vergessen Sie nicht, dies zu / etc / profile oder / etc / bashrc hinzuzufügen, so dass es auch für Ihre Entwickler voreingestellt ist - Mark Porter


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

  • / 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 verwalten, werden in eine Gruppe für die Website aufgenommen.
  • Diese Gruppe wird als Gruppenbesitzer aller Dateien und Ordner im Verzeichnis festgelegt.
  • Alle Dateien oder Ordner, die vom Webserver geschrieben werden müssen (z. B. PHP), haben ihren Besitzer in www-data geändert, den Benutzer, unter dem apache läuft.

Beachten Sie, dass Sie das Ausführungsbit in Verzeichnissen aktivieren müssen, damit Sie den Inhalt auflisten können.


8
2018-03-22 02:52



Wie erstellt git / svn oder PHP dann neue Ordner? - Xeoncross
PHP läuft im selben Benutzerkontext wie der Webserver, so dass es Dateien und Ordner in jedem Verzeichnis des Webservers erstellen kann. Es gibt im Allgemeinen nur ein paar Ordner wie diese (/ uploads / zum Beispiel). Ich bin mir nicht sicher über git / svn - könnten Sie sie zum Gruppenkonto hinzufügen, das die Website steuert? - Nic
Offensichtlich läuft git so, wie der Benutzer es ausführt - genau wie jedes andere Tool. - Xeoncross
Fügen Sie dann den Git-Benutzer zur Apache-Gruppe hinzu und geben Sie der Ordnergruppe Schreibberechtigungen. - David Rickman
Ich sagte gerade, Git hat keinen Benutzer - es läuft als der aktuelle Benutzer, der es benutzt. - Xeoncross


Nach mehr Forschung scheint es, dass git / svn WERKZEUGE sind kein Problem, da sie wie jeder Benutzer ausgeführt werden. (Die git / svn-Dämonen sind jedoch eine andere Sache!) Alles, was ich mit git erstellt / geklont habe, hatte meine Berechtigungen und das git-Tool wurde aufgelistet /usr/bin Das passt zu dieser These.

Git Berechtigungen gelöst.

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

So scheint es eine Antwort Um diese Frage geht es so:

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

1) Ändern Sie den Gruppeninhaber

Zuerst müssen wir die www-Verzeichnisgruppe ändern, die von "www-data" anstelle von "root" -Gruppe gehört

sudo chgrp -R www-data /var/www

2) Fügen Sie Benutzer zu www-Daten hinzu

Dann müssen wir den aktuellen Benutzer (und alle anderen) zur WWW-Datengruppe hinzufügen

sudo usermod -a -G www-data demousername

3) CHMOD www Verzeichnis

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

sudo chmod -R 2770 /var/www

Jetzt werden alle Dateien und Verzeichnisse, die von jedem Benutzer, der Zugriff hat (d. H. In der Gruppe "www-data"), von Apache und damit von php gelesen / geschrieben werden können.

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


6
2018-03-24 03:15



Ich mag die Idee nicht, dass alle Web-Dateien von PHP beschreibbar sind, es erhöht Ihre mögliche Exposition, wenn es eine Skript-Schwachstelle gibt. - Nic
Ok, ich weiß, ich benutze PHP um viele zu erstellen Text, Teer, Protokoll und Bild Dateien (plus Ordner), also nahm ich nur an, dass alles beschreibbar sein sollte. Aber vielleicht sollte dein Recht und PHP nur dazu in der Lage sein ÄNDERN SIE DATEIEN, DIE SIE ERSTELLT Das wäre harmlos, da 99% aller PHP-Apps keine Skriptdateien erstellen. Die andere Wahl scheint zu sein, nur bestimmten Verzeichnissen PHP den Schreibzugriff zu erlauben (/ uploads /) was das nicht macht, denn dann könnte PHP noch dazu benutzt werden, dort etwas schlechtes zu erstellen. Irgendwelche Ideen? - Xeoncross
Versuchen Sie, Skript und Daten getrennt zu halten. Selbst wenn ein Angreifer etwas in / uploads / ablegen kann, sollte es nicht ausführbar sein. Sicherheit in Schichten ist der Schlüssel. - Nic


Klebrigkeit ist keine Vererbung von Berechtigungen. Klebrigkeit in einem Verzeichnis bedeutet, dass nur der Eigentümer einer Datei oder der Verzeichnisbesitzer diese Datei im Verzeichnis umbenennen oder löschen kann, obwohl die Berechtigungen anders lauten. Also 1777 an / tmp /.

Im klassischen Unix gibt es keine Vererbung von Berechtigungen basierend auf dem Dateisystem, nur auf dem aktuellen Prozess umask. Unter * BSD oder Linux mit setgid im Verzeichnis wird das Gruppenfeld der neu erstellten Dateien auf das gleiche wie das des übergeordneten Verzeichnisses gesetzt. Für alles Weitere müssen Sie in ACLs nachsehen, mit der 'Standard' ACL für Verzeichnisse, mit denen Sie die Berechtigungen geerbt haben.

Du solltest anfangen mit:  * Welche Benutzer haben Zugriff auf das System?  * Was ist Ihr Bedrohungsmodell?

Wenn Sie beispielsweise Webhosting mit mehreren Kunden durchführen und nicht möchten, dass sie sich gegenseitig die Dateien sehen, verwenden Sie möglicherweise eine gemeinsame Gruppe "webcusts" für alle diese Benutzer und einen Verzeichnismodus von 0705. Dann werden die Dateien von der Webserver-Prozess (nicht in "webcusts") werden die anderen Dauerwellen angezeigt und erlaubt sein; Kunden können ihre Dateien nicht sehen und die Benutzer können sich mit ihren eigenen Dateien anlegen. Dies bedeutet jedoch, dass Sie in dem Moment CGI oder PHP zulassen haben um sicherzustellen, dass die Prozesse als der spezifische Benutzer ausgeführt werden (bewährte Methode für mehrere Benutzer auf einem Host für Rechenschaftspflicht). Andernfalls könnten die Kunden sich gegenseitig mit den Dateien der anderen durcheinander bringen, indem sie ein CGI verwenden.

Wenn der Laufzeitbenutzer für eine Website jedoch mit dem Eigentümer der Website identisch ist, haben Sie Probleme, den Inhalt im Falle einer Sicherheitslücke im Skript nicht vor Missbrauch zu schützen. Das ist der Punkt, an dem dedizierte Hosts gewinnen, so dass Sie einen Laufzeitbenutzer haben, der sich vom Eigentümer des statischen Inhalts unterscheidet und sich nicht so sehr Gedanken über die Interaktion mit anderen Benutzern machen muss.


5
2018-03-22 03:37



Gute Antwort. Unter MacOS X verhält sich das System so, als wäre das SGID-Bit automatisch in den Verzeichnissen. Das Sticky-Bit bedeutet normalerweise, dass Sie die Datei nur entfernen können, wenn Sie sie schreiben können. Das heißt, jeder kann eine öffentlich schreibbare Datei in / tmp entfernen. Auf MacOS X ist / tmp ein Symlink zu einem privaten Verzeichnis für den Benutzer - also gibt es überhaupt keine Freigabe. - Jonathan Leffler
Danke für die Antwort, ich habe die Frage mit weiteren Informationen aktualisiert. - Xeoncross
Jonathan: Das Sticky-Bit bedeutet, dass nur der Besitzer des Verzeichnisses oder der Besitzer der Datei es umbenennen oder löschen kann (dh, nach seinem Eintrag im Verzeichnis 'Datei' handeln). Berechtigungen für die einzelnen Dateien spielen bei diesen Verzeichnisoperationen keine Rolle (rename(), unlink()), nur für Aktionen in der Datei selbst (open()). Dies ist das "übliche" Verhalten. - Phil P


Ich glaube, dass der beste Weg dies zu tun ist mit Posix ACLs. Sie sind komfortabel zu bedienen und bieten alle Funktionen, die Sie benötigen.

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

Hier finden Sie eine Anleitung zur Verwendung von ACLs. Abhängig von Ihrer Distribution enthält Ihr Kernel möglicherweise bereits ACL-Unterstützung.

http://www.cs.unc.edu/cgi-bin/howto?howto=linux-posix-acls


2
2018-03-26 10:44



+1 für hilfreiche Informationen zu ACLs. Ich möchte jedoch nicht, dass zusätzlicher Junk-Up das System in den Ruin treibt, nur um einen einfachen Server mit ein paar Entwicklern zu verwalten. Ich bin auch nicht damit zufrieden, den Kernel neu zu kompilieren, um ACLs zu verwenden. - Xeoncross
@Xeoncross: ACLs machen nichts kaputt. Sie sind nur Metainformationen wie normale Dateiberechtigungen. Es ist nicht alles "extra" und kompliziert, ich glaube, dass es der einfachste und beste Weg ist, um Berechtigungen zu verwalten, anstatt irgendeine verwirrende klebrige / Gruppe / was auch immer Lösung. Haben Sie keine Angst, einfach wieder mit acl und probieren Sie es aus! - Tie-fighter


Der Eigentümer der Datei sollte die Person sein, die sie erstellt, während die Gruppe www-Daten sein sollte. Der Modus für Verzeichnisse / Dateien ist dann generell 755/644. Während die Gruppe für Verzeichnisse und Dateien Schreibzugriff benötigt, ist die Mod 775/664. Angenommen, Paddy ist der Entwickler. Insgesamt macht das:

chown -R paddy:www-data /var/www/websiteindevelopment
chmod -R 755 /var/www/websiteindevelopment
chmod -R 775 /var/www/websiteindevelopment/directorywritablebygroup
find /var/www/websiteindevelopment -type f -perm 755 -print -exec chmod 644 {} \;  
find /var/www/websiteindevelopment -type f -perm 775 -print -exec chmod 664 {} \;

1
2017-09-24 18:08





Zu @ Xeoncross Antwort hinzufügen, ich denke, es wäre gut, Berechtigungen für Dateien und Verzeichnisse separat zu konfigurieren.

sudo find /var/www -type d -exec chmod 775 {} \;  # Change permissions of directories to rwxrwxr-x
sudo find /var/www -type f -exec chmod 664 {} \;  # Change file permissions to rw-rw-r--

Dies ermöglicht Entwicklern das Erstellen und Ändern von Verzeichnissen innerhalb von / var / www. Das scheint wichtig zu sein, da Entwickler möglicherweise zusätzliche Verzeichnisse erstellen oder ein Verzeichnis löschen müssen, das nicht mehr benötigt wird.

Entwickler können auch Code-Dateien erstellen und ändern (lesen Sie HTML, PHP-Dateien und ähnliches). Aber, wird immer noch nur Lesezugriff für alle anderen erlauben.


0
2017-12-09 05:38