Die von bgles veröffentlichte Lösung ist genau das Richtige für mich, wenn es darum geht, Berechtigungen anfangs korrekt festzulegen (ich verwende die zweite Methode), aber es gibt immer noch potenzielle Probleme für Laravel.
Standardmäßig erstellt Apache Dateien mit 644 Berechtigungen. Das ist also so ziemlich alles im Speicher. Wenn Sie also den Inhalt von Speicher / Framework / Ansichten löschen und über Apache auf eine Seite zugreifen, wird die zwischengespeicherte Ansicht wie folgt erstellt:
-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2
Wenn Sie "Artisan Serve" ausführen und auf eine andere Seite zugreifen, erhalten Sie unterschiedliche Berechtigungen, da sich CLI PHP anders als Apache verhält:
-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e
An sich ist dies keine große Sache, da Sie dies in der Produktion nicht tun werden. Wenn Apache jedoch eine Datei erstellt, die anschließend vom Benutzer geschrieben werden muss, schlägt dies fehl. Dies kann für Cache-Dateien, zwischengespeicherte Ansichten und Protokolle gelten, wenn die Bereitstellung mit einem angemeldeten Benutzer und Handwerker erfolgt. Ein einfaches Beispiel ist "artisan cache: clear", bei dem keine Cache-Dateien gelöscht werden können, die www-data: www-data 644 sind.
Dies kann teilweise gemildert werden, indem handwerkliche Befehle als WWW-Daten ausgeführt werden. Sie werden also alles tun / skripten wie:
sudo -u www-data php artisan cache:clear
Oder Sie vermeiden die Langeweile und fügen dies Ihren .bash_aliases hinzu:
alias art='sudo -u www-data php artisan'
Dies ist gut genug und beeinträchtigt die Sicherheit in keiner Weise. Das Ausführen von Test- und Hygieneskripten auf Entwicklungsmaschinen macht dies jedoch unhandlich, es sei denn, Sie möchten Aliase einrichten, um 'sudo -u www-data' zum Ausführen von phpunit zu verwenden, und alles andere, mit dem Sie Ihre Builds überprüfen, kann dazu führen, dass Dateien erstellt werden.
Die Lösung besteht darin, dem zweiten Teil der Bgles-Ratschläge zu folgen, Folgendes zu / etc / apache2 / envvars hinzuzufügen und Apache neu zu starten (nicht neu zu laden):
umask 002
Dadurch wird Apache gezwungen, standardmäßig Dateien als 664 zu erstellen. Dies kann an sich ein Sicherheitsrisiko darstellen. In den hier meist diskutierten Laravel-Umgebungen (Homestead, Vagrant, Ubuntu) wird der Webserver jedoch als Benutzer-www-Daten unter der Gruppe www-Daten ausgeführt. Wenn Sie Benutzern also nicht willkürlich erlauben, der www-Datengruppe beizutreten, sollte kein zusätzliches Risiko bestehen. Wenn es jemandem gelingt, aus dem Webserver auszubrechen, hat er ohnehin eine WWW-Datenzugriffsebene, sodass nichts verloren geht (obwohl dies zugegebenermaßen nicht die beste Einstellung in Bezug auf Sicherheit ist). In der Produktion ist es also relativ sicher, und auf einer Einzelbenutzer-Entwicklungsmaschine ist dies einfach kein Problem.
Da sich Ihr Benutzer in der WWW-Datengruppe befindet und alle Verzeichnisse, die diese Dateien enthalten, g + s sind (die Datei wird immer unter der Gruppe des übergeordneten Verzeichnisses erstellt), ist alles, was vom Benutzer oder von WWW-Daten erstellt wird, r /. w für den anderen.
Und das ist das Ziel hier.
bearbeiten
Wenn Sie den obigen Ansatz zum weiteren Festlegen von Berechtigungen untersuchen, sieht er immer noch gut genug aus, aber ein paar Verbesserungen können helfen:
Standardmäßig sind Verzeichnisse 775 und Dateien 664, und alle Dateien haben den Eigentümer und die Gruppe des Benutzers, der gerade das Framework installiert hat. Nehmen wir also an, wir beginnen an diesem Punkt.
cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./
Als erstes blockieren wir den Zugriff auf alle anderen und machen die Gruppe zu WWW-Daten. Nur der Eigentümer und die Mitglieder von www-data können auf das Verzeichnis zugreifen.
sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache
Damit der Webserver services.json und compiled.php erstellen kann, wie im offiziellen Laravel-Installationshandbuch vorgeschlagen. Das Setzen des Gruppen-Sticky-Bits bedeutet, dass diese dem Ersteller mit einer Gruppe von WWW-Daten gehören.
find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage
Wir machen dasselbe mit dem Speicherordner, um die Erstellung von Cache-, Protokoll-, Sitzungs- und Ansichtsdateien zu ermöglichen. Wir verwenden find, um die Verzeichnisberechtigungen für Verzeichnisse und Dateien explizit unterschiedlich festzulegen. Wir mussten dies nicht in Bootstrap / Cache tun, da dort (normalerweise) keine Unterverzeichnisse vorhanden sind.
Möglicherweise müssen Sie alle ausführbaren Flags erneut anwenden, Vendor / * löschen und Composer-Abhängigkeiten neu installieren, um Links für phpunit et al. Neu zu erstellen, z.
chmod +x .git/hooks/*
rm vendor/*
composer install -o
Das ist es. Mit Ausnahme der oben erläuterten Umask für Apache ist dies alles, was erforderlich ist, ohne dass die gesamte Projektwurzel durch www-Daten beschreibbar ist, was bei anderen Lösungen der Fall ist. Auf diese Weise ist es etwas sicherer, wenn ein Eindringling, der als WWW-Daten ausgeführt wird, einen eingeschränkteren Schreibzugriff hat.
Ende bearbeiten
Änderungen für Systemd
Dies gilt für die Verwendung von php-fpm, aber möglicherweise auch für andere.
Der Standarddienst systemd muss überschrieben, die Umask in der Datei override.conf festgelegt und der Dienst neu gestartet werden:
sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service
777ist zu viel Freiheit, weil es alle Berechtigungen für alle beinhaltet.