Wie zum einrichten der Datei-Berechtigungen für Laravel 5 (und andere)

Nur um das offensichtliche für alle Leser dieser Diskussion.... wenn Sie geben jedem Ihrer Ordner von 777 Berechtigungen, die Sie erlauben, JEMAND zu Lesen, zu schreiben und führen Sie eine Datei in das Verzeichnis.... was dies bedeutet ist Sie haben JEDERMANN (jeden hacker oder eine böswillige person in der ganzen Welt) die Berechtigung zum hochladen von Dateien, Viren oder andere Datei, und führen Sie DANN die Datei...

WENN SIE IHRE ORDNER-BERECHTIGUNGEN AUF 777, DIE SIE GEÖFFNET HABEN IHRE
SERVER FÜR JEDEN, FINDEN DAS VERZEICHNIS. Deutlich genug??? 🙂

Grundsätzlich gibt es zwei Möglichkeiten zum einrichten der Zugriffsberechtigungen und Eigentum. Entweder geben Sie sich selbst das Eigentum, oder Sie machen den webserver, der Besitzer aller Dateien.

Webserver als Besitzer (wie die meisten Menschen tun es, und die Laravel doc ' s Weg):

vorausgesetzt, www-data (es könnte etwas anderes sein) ist und der webserver-Benutzer.

 sudo chown -R www-data:www-data /Pfad/zu/deinem/laravel/root/Verzeichnis

wenn Sie das tun, ist der webserver besitzt Sie alle Dateien, und ist auch die Gruppe, und Sie haben etwas Probleme beim Upload von Dateien oder bei der Arbeit mit Dateien über FTP, weil Ihre FTP-client wird angemeldet sein wie Sie, nicht auf Ihrem webserver, so fügen Sie Ihren Benutzer zu der webserver-Benutzer Gruppe:

 sudo usermod-a -G www-data ubuntu -

Natürlich, dies setzt Voraus, Ihr webserver läuft als www-data (der Standard-Homestead), und Ihre Benutzer ubuntu (es ist wandernden, wenn Sie mit Homestead).

Dann stellen Sie alle Ihre Verzeichnisse auf 755 und Dateien auf 644...
SET-Datei Berechtigungen

sudo find /path/to/your/laravel/root/Verzeichnis -type f -exec chmod 644 {} \; 

SET directory-Berechtigungen

sudo find /path/to/your/laravel/root/Verzeichnis -type d -exec chmod 755 {} \;

Ihrem Benutzer als Besitzer

Ich lieber selber alle Verzeichnisse und Dateien (es macht die Arbeit mit dem alles viel einfacher), so dass ich tun:

sudo chown -R meine-user:www-data /Pfad/zu/deinem/laravel/root/Verzeichnis

Dann gebe ich mich und die webserver-Berechtigungen:

sudo find /path/to/your/laravel/root/Verzeichnis -type f -exec chmod 664 {} \; 
sudo find /path/to/your/laravel/root/Verzeichnis -type d -exec chmod 775 {} \;

Dann geben die Server die Rechte zum Lesen und schreiben auf Speicher und cache

Welcher Art und Weise Sie es eingerichtet haben, dann müssen Sie lese-und Schreibrechte für den webserver für die Speicherung, cache und alle anderen Verzeichnisse, die der webserver benötigt, um zu laden oder zu schreiben (je nach situation), so führen Sie die Befehle von bashy oben :

sudo chgrp -R www-data storage-bootstrap/cache 
sudo chmod -R ug+rwx storage-bootstrap/cache

Nun, Sie sind sicher und Ihre website funktioniert, UND Sie können die Dateien relativ leicht

Wir haben in vielen Grenzfälle beim einrichten der Berechtigungen für Laravel Applikationen. Wir erstellen ein eigenes Benutzerkonto (deploy) für die Eigentümer der Laravel application-Ordner und ausführen von Laravel-Kommandos von der Kommandozeile, und führen Sie den web-server unter www-data. Ein Problem, das bewirkt, dass die log-Datei(en) ist möglicherweise im Besitz von www-data oder deploy, je nachdem, wer schrieb, um die log-Datei zuerst, die offensichtlich verhindern, das andere user schreiben, Sie in der Zukunft.

Habe ich herausgefunden, dass die einzige vernünftige und sichere Lösung ist der Einsatz von Linux-ACLs. Das Ziel dieser Lösung ist:

1. Um dem Benutzer zu erlauben, wer besitzt/stellt die Anwendung lese-und Schreibzugriff auf die Laravel application code (wir verwenden einen Benutzer mit dem Namen deploy).
2. Zu ermöglichen, die www-data Benutzer lese-Zugriff auf Laravel application-code, aber keinen Schreibzugriff.
3. Um zu verhindern, dass andere Benutzer Zugriff auf die Laravel application code/Daten an allen.
4. Ermöglicht sowohl die www-data Benutzer und die Benutzer der Anwendung (deploy) schreiben Zugriff auf den Ordner storage, unabhängig davon, welcher Benutzer der Eigentümer der Datei (also beide deploy und www-data schreiben können, um die gleiche log-Datei, zum Beispiel).

Dies erreichen wir wie folgt:

1. Alle Dateien innerhalb des application/ Ordner erstellt werden, die Standard-umask von 0022, die Ergebnisse in Ordnern mit drwxr-xr-x Berechtigungen und Dateien, die mit -rw-r--r--.
2. sudo chown -R deploy:deploy application/ (oder einfach nur das bereitstellen Ihrer Anwendung als deploy Benutzer, das ist, was wir tun).
3. chgrp www-data application/ zu geben, die www-data Gruppe den Zugriff auf die Anwendung.
4. chmod 750 application/ zu ermöglichen, die deploy Benutzer Lesen/schreiben, die www-data Benutzer schreibgeschützt, und entfernen Sie alle Berechtigungen für andere Benutzer.
5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/ um die Standard-Berechtigungen auf den storage/ Ordner und alle Unterordner. Jeder neue Ordner/Dateien erstellt, in den Ordner storage, Erben diese Berechtigungen (rwx für beide www-data und deploy).
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ um die oben genannten Berechtigungen auf alle vorhandenen Dateien/Ordner.

Als gebucht, bereits

Alles, was Sie tun müssen, ist, um Besitz von dem Ordner zu Apache :

aber ich habe -R für chown Befehl:

sudo chown -R www-data:www-data /path/to/your/project/vendor
sudo chown -R www-data:www-data /path/to/your/project/storage


Die Lösung gepostet von bgles ist vor Ort auf für mich, in Bezug auf korrekt festlegen von Berechtigungen anfangs (als ich die zweite Methode verwenden), aber es hat immer noch mögliche Probleme für die Laravel.

Standardmäßig wird der Apache erstellen von Dateien mit 644 Berechtigungen. Also das ist so ziemlich alles in storage/. Also, wenn Sie löschen Sie den Inhalt des Speichers/framework/views, dann eine Seite zuzugreifen, die über Apache finden Sie die zwischengespeicherte Ansicht erstellt wurde, wie:

-rw-r--r-- 1 www-data www-data 1005 Dec  6 09:40 969370d7664df9c5206b90cd7c2c79c2

Wenn Sie "artisan serve" und auf eine andere Seite, erhalten Sie unterschiedliche Berechtigungen, da der CLI-PHP verhält sich anders als Apache:

-rw-rw-r-- 1 user     www-data 16191 Dec  6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e

In sich, dies ist keine große Sache, da werden Sie nicht tun, jede dieser in der Produktion. Aber wenn Apache eine Datei erstellt, die später benötigt werden, vom Benutzer geschrieben, wird es scheitern. Und diese kann anwenden, um cache-Dateien, zwischengespeicherten Ansichten und Protokolle, die bei der Bereitstellung mit einem angemeldeten Benutzer und Handwerker. Eine einfache Beispiel "Handwerker-cache:klar," das wird nicht löschen Sie alle cache-Dateien, die www-data:www-data 644.

Diese werden teilweise gemildert durch die Ausführung artisan Befehle als www-data, so werden Sie tun/scripting alles wie:

sudo -u www-data php artisan cache:clear

Oder Sie vermeiden die Langweiligkeit dieses und fügen Sie diese zu Ihrem .bash_aliases:

alias art='sudo -u www-data php artisan'

Ist das gut genug und ist nicht auf die Sicherheit in irgendeiner Weise. Aber auf die Entwicklung von Maschinen, ausführen von Prüf-und Hygiene-Skripten macht diese unhandlich, es sei denn, Sie möchten einrichten Aliasnamen für die Verwendung von 'sudo -u www-data' zum ausführen von phpunit und alles, was Sie überprüfen Sie Ihre builds mit verursachen könnte-Dateien erstellt werden.

Die Lösung ist, folgt der zweite Teil der bgles Beratung, und fügen Sie Folgendes zu /etc/apache2/envvars, und neu starten (nicht neu laden) - Apache:

umask 002

Diese zwingen den Apache zu erstellen, Dateien 664 standardmäßig. An sich, dies kann ein Sicherheitsrisiko darstellen. Aber auf das Laravel-Umgebungen meist diskutiert hier (Homestead, Vagrant, Ubuntu) der web-server läuft als user www-data unter die Gruppe www-data. Also, wenn Sie nicht willkürlich erlauben Benutzern, an www-data Gruppe soll es kein zusätzliches Risiko. Wenn es jemand schafft, um aus den webserver, Sie haben www-data access level sowieso, so dass nichts verloren geht (obwohl das nicht die beste Einstellung zu haben bezüglich der Sicherheit, zugegeben). Also auf Produktion, es ist relativ sicher, und auf einem single-user-Entwicklung-Maschine, es ist nicht nur ein Problem.

Letztlich als user ist www-data der Gruppe, und alle Verzeichnisse mit diesen Dateien sind g+s (die Datei wird immer erstellt, unter der Gruppe der Eltern-Verzeichnis), alles durch den Benutzer erstellt oder von www-Daten r/w-für die anderen.

... Und das ist es hier das Ziel.

Bearbeiten

Auf die Untersuchung des oben erwähnten Ansatz zum festlegen von Berechtigungen weiter, es sieht immer noch gut genug, aber ein paar Kniffe, die helfen können:

Standardmäßig Verzeichnisse 775 und Dateien 664 und alle Dateien haben den Eigentümer und die Gruppe des Benutzers nur installiert das framework. So übernehmen wir starten von diesem Punkt aus.

cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./

Erste, was wir tun, ist, blockieren Sie den Zugriff auf alle anderen, und stellen Sie der Gruppe www-data. Nur der Besitzer und die Mitglieder der www-data kann auf das Verzeichnis zugreifen.

sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache

Erlauben dem webserver zu erstellen Dienstleistungen.json und compiled.php, wie vorgeschlagen, durch die offizielle Laravel installation guide. Einstellen der Gruppen-sticky-bit bedeutet, dass diese im Besitz der Schöpfer mit einer Gruppe von www-data.

find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage

Wir tun das gleiche mit dem Speicher-Ordner ermöglichen die Erstellung von cache, log, session und anzeigen von Dateien. Wir suchen explizit den directory-Berechtigungen anders für Verzeichnisse und Dateien. Wir brauchen nicht, dies zu tun in der bootstrap/cache gibt es nicht (normalerweise) alle sub-Verzeichnisse dort.

Müssen Sie möglicherweise erneut executable-flags und löschen von Verkäufer/* und installieren Sie composer Abhängigkeiten zu erstellen-links für phpunit et al, zB:

chmod +x .git/hooks/*
rm vendor/*
composer install -o

Das ist es. Außer für die umask für den Apache oben erklärt, das ist alles, was erforderlich ist, ohne dass die ganze projectroot writeable by www-data, das ist, was passiert mit anderen Lösungen. So ist es geringfügig sicherer, auf diese Weise, dass ein Eindringling läuft als www-data hat mehr der Schreibzugriff eingeschränkt.

Ende Bearbeiten

Änderungen für Systemd

Dies gilt für die Verwendung von php-fpm, aber vielleicht auch andere.

Standard systemd service muss überschrieben werden, die umask gesetzt, in den override.conf-Datei, und der Dienst neu gestartet wird:

sudo systemctl edit php7.0-fpm.service
Use:
    [Service]
    UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service

Habe ich installiert laravel auf EC2-Instanz und habe 3 Tage zu beheben, die Erlaubnis, Fehler endlich behoben.
So möchte ich teilen diese Erfahrung mit anderen.

1. Benutzer problem
   Wenn ich eingeloggt ec2-instance, mein Benutzername ist " ec2-user und usergroup ist ec2-user.
   Und die website funktioniert, unter der httpd-user: apache: apache
   also sollten wir die Rechte für apache.

2. Ordner-und Datei-Berechtigung
   A. Ordner-Struktur
   zunächst sollten Sie sicherstellen, dass Sie die Ordner-Struktur wie diese unter Speicher

   Lagerung

   • Rahmen
     • cache
     • Sitzungen
     • Ansichten
   • Protokolle
     Die Ordner-Struktur kann unterschiedlich sein nach der laravel-version, die Sie verwenden.
     meine laravel-version ist 5.2 und Sie könnten finden die geeignete Struktur, abhängig von Ihrer version.

B. Genehmigung
Auf den ersten, sehe ich die Anweisungen, um festzulegen, 777 unter Speicher zu entfernen file_put_contents: failed to open stream Fehler.
Also richte ich die Berechtigung 777 zu Speicher
chmod -R 777-Speicher
Aber der Fehler wurde nicht behoben.
hier sollten Sie überlegen: wer schreibt Dateien auf storage/sessions und Ansichten.
Das ist nicht "ec2-user", aber apache.
Ja, richtig.
"apache" user schreibt Datei (session-Datei, die kompilierten Datei anzeigen), um die Sitzung und Ordner anzeigen.
So sollten Sie geben der apache Schreibzugriff auf diesen Ordner.
Standardmäßig ist SELinux sagen, das /var/www Ordner schreibgeschützt sein sollte, die von der apache-Dämon.

Also, für dieses, können wir die selinux-0:
setenforce 0

Kann dieses problem lösen zeitlich, aber das macht das mysql nicht funktioniert.
das ist also keine so gute Lösung.

Können Sie eine Lesen-schreiben-Kontext auf den storage-Ordner mit: (denkt daran, setenforce 1, um es zu testen)

chcon -Rt httpd_sys_content_rw_t storage/

Dann ist dein problem behoben wird.

1. und vergessen Sie nicht, dieses
   Komponist update
   php artisan-cache:klar

   Diese Befehle nützlich sein wird, nachdem oder bevor.

   Ich hoffe, dass Sie Ihre Zeit sparen.
   Viel Glück. Hacken

Habe ich mich dazu entschlossen, mein eigenes Skript zu lindern einige der Schmerzen für die Einrichtung von Projekten.

Führen Sie den folgenden innerhalb Ihrer Projekt-root:

wget -qO- https://raw.githubusercontent.com/defaye/bootstrap-laravel/master/bootstrap.sh | sh

Warten bootstrapping-Vorgang abgeschlossen und du bist gut zu gehen.

Überprüfen Sie das Skript vor der Verwendung.

Fand ich eine noch bessere Lösung.
Seine verursacht, weil php läuft als ein anderer Benutzer standardmäßig.

so, um dieses Problem beheben zu tun

sudo nano /etc/php/7.0/fpm/pool.d/www.conf

Bearbeiten Sie dann die

user = "put user that owns the directories"
group = "put user that owns the directories"


dann:

sudo systemctl reload php7.0-fpm