it-swarm.com.de

So richten Sie Dateiberechtigungen für Laravel 5 (und andere) ein

Ich verwende Apache Web Server, für den der Besitzer auf _www:_www eingestellt ist. Ich weiß nie, was die beste Vorgehensweise bei Dateiberechtigungen ist, zum Beispiel, wenn ich ein neues Laravel 5-Projekt erstelle.

Für Laravel 5 muss der /storage-Ordner beschreibbar sein. Ich habe viele verschiedene Ansätze gefunden, damit es funktioniert. Ich ende normalerweise damit, 777 chmod rekursiv zu machen. Ich weiß, dass es nicht die beste Idee ist.

Das offizielle Dokument sagt:

Für Laravel müssen möglicherweise einige Berechtigungen konfiguriert werden: Ordner innerhalb von storage und vendor erfordern Schreibzugriff vom Webserver.

Bedeutet das, dass der Webserver auch auf die Ordner storage und vendor selbst oder nur auf deren aktuellen Inhalt zugreifen muss?

Ich gehe davon aus, dass das, was viel besser ist, den Besitzer anstelle von Berechtigungen ändert. Ich habe alle Dateiberechtigungen von Laravel rekursiv in _www:_www geändert, und das hat dazu geführt, dass die Site korrekt funktioniert, als ob ich chmod in 777 geändert hätte. Das Problem ist, dass mein Texteditor mich jetzt jedes Mal nach einem Kennwort fragt, wenn ich eine Datei speichern möchte. Dies geschieht auch, wenn ich versuche, etwas im Finder zu ändern, beispielsweise eine Datei zu kopieren.

Was ist der richtige Ansatz, um diese Probleme zu lösen?

  1. chmod ändern
  2. Ändern Sie den Besitzer der Dateien so, dass er denen von .__ entspricht. Webserver und stellen Sie möglicherweise den Texteditor (und den Finder?) auf Überspringen nach dem Passwort fragen oder sie verwenden, Sudo
  3. Ändern Sie den Besitzer des Webservers so, dass er mit dem Benutzer os übereinstimmt.
  4. Etwas anderes
121
Robo Robok

Um nur das Offensichtliche für jeden anzuzeigen, der sich diese Diskussion ansieht ... Wenn Sie einem Ihrer Ordner 777 Berechtigungen erteilen, gestatten Sie, dass JEDER JEDER eine beliebige Datei in diesem Verzeichnis lesen, schreiben und ausführen kann JEDERMANN (jeglicher Hacker oder böswillige Person auf der ganzen Welt) die Erlaubnis zum Hochladen einer beliebigen Datei, eines Virus oder einer anderen Datei und DANN dann die Datei ausführen ... 

WENN SIE IHRE VERTRIEBSPUNKTE AUF 777 EINSTELLEN, HABEN SIE IHRE ERÖFFNET. SERVER FÜR JEDER, DER DIESES VERZEICHNIS FINDEN KANN. Klar genug??? :)

Es gibt grundsätzlich zwei Möglichkeiten, Ihren Besitz und Ihre Berechtigungen festzulegen. Entweder Sie geben sich das Eigentum oder Sie machen den Webserver zum Eigentümer aller Dateien.

Webserver als Besitzer (so wie es die meisten Leute machen und auf die Art des Laravel-Dokuments):

vorausgesetzt, www-data (es könnte etwas anderes sein) ist Ihr Webserver-Benutzer.

    Sudo chown -R www-data: www-data/pfad/zum/Ihrem/laravel/rootVerzeichnis

wenn Sie dies tun, besitzt der Webserver alle Dateien und ist auch die Gruppe. Beim Hochladen von Dateien oder beim Arbeiten mit Dateien über FTP treten Probleme auf, da Ihr FTP-Client als Sie und nicht Ihr Webserver angemeldet ist Ihr Benutzer zur Webserver-Benutzergruppe:

   Sudo usermod -a -G www-data ubuntu

Dies setzt natürlich voraus, dass Ihr Webserver als www-data (Standardeinstellung von Homestead) ausgeführt wird und Ihr Benutzer Ubuntu ist (er ist vagrant, wenn Sie Homestead verwenden).

Dann setzen Sie alle Ihre Verzeichnisse auf 755 und Ihre Dateien auf 644 ... SET-Dateiberechtigungen

Sudo find/path/to/your/laravel/root/verzeichnistyp f -exec chmod 644 {} \; 

SET-Verzeichnisberechtigungen

Sudo find/path/to/your/laravel/root/verzeichnistyp d -exec chmod 755 {} \;

/ - Dein Benutzer als Besitzer

Ich ziehe es vor, alle Verzeichnisse und Dateien zu besitzen (dadurch wird die Arbeit mit allem viel einfacher), also mache ich: 

Sudo chown -R mein Benutzer: www-data/path/zu/your/laravel/root/verzeichnis

Dann gebe ich sowohl mir als auch dem Webserver die Berechtigungen: 

Sudo find/path/to/your/laravel/root/verzeichnistyp f -exec chmod 664 {} \; 
 Sudo find/path/to/your/laravel/root/verzeichnis -type d -exec chmod 775 {} \;

Geben Sie dem Webserver dann die Rechte zum Lesen und Schreiben in den Speicher und Cache

Wie auch immer Sie es einrichten, Sie müssen dem Webserver Lese- und Schreibrechte für Speicher, Cache und alle anderen Verzeichnisse geben, die der Webserver zum Hochladen oder Schreiben benötigt (abhängig von Ihrer Situation). Führen Sie also die oben genannten Befehle von bashy aus:

Sudo chgrp -R www-Datenspeicher-Bootstrap/cache 
 Sudo chmod -R ug + rwx-Speicher-Bootstrap/cache

Jetzt sind Sie sicher und Ihre Website funktioniert UND Sie können ziemlich einfach mit den Dateien arbeiten

376
bgies

Die Berechtigungen für die Ordner storage und vendor sollten aus offensichtlichen Sicherheitsgründen bei 775 verbleiben.

Allerdings müssen sowohl Ihr Computer als auch Ihr Server Apache in diese Ordner schreiben können. Beispiel: Wenn Sie Befehle wie php artisan ausführen, muss Ihr Computer in die Protokolldatei in storage schreiben.

Alles, was Sie tun müssen, ist, Apache den Besitz der Ordner zu übertragen: 

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

Dann müssen Sie Ihren Computer (referenziert durch username) der Gruppe hinzufügen, zu der der Server Apache gehört. So wie: 

Sudo usermod -a -G www-data userName

HINWEIS: Am häufigsten ist groupNamewww-data, aber ersetzen Sie es in Ihrem Fall durch _www.

36
BassMHL

Ändern Sie die Berechtigungen für Ihren Projektordner, um Lesen/Schreiben/Ausführen für alle Benutzer innerhalb der Gruppe zu ermöglichen, die das Verzeichnis besitzt (in Ihrem Fall _www):

chmod -R 775 /path/to/your/project

Fügen Sie dann Ihren OS X-Benutzernamen der _www-Gruppe hinzu, um Zugriff auf das Verzeichnis zu erhalten:

Sudo dseditgroup -o edit -a yourusername -t user _www
12
Bogdan

Bei der Einrichtung von Berechtigungen für Laravel-Anwendungen sind viele Edge-Fälle aufgetreten. Wir erstellen ein separates Benutzerkonto (deploy), um den Laravel-Anwendungsordner zu besitzen und Laravel-Befehle über die CLI auszuführen, und den Webserver unter www-data ausführen. Ein Problem, das dadurch verursacht wird, ist, dass die Protokolldatei (en) möglicherweise www-data oder deploy gehört. Dies hängt davon ab, wer zuerst in die Protokolldatei geschrieben hat, was den anderen Benutzer offensichtlich daran hindert, in die Zukunft zu schreiben.

Ich habe festgestellt, dass die einzige vernünftige und sichere Lösung die Verwendung von Linux-ACLs ist. Das Ziel dieser Lösung ist:

  1. Um dem Benutzer, der die Anwendung besitzt/implementiert, Lese- und Schreibzugriff auf den Laravel-Anwendungscode zu ermöglichen (wir verwenden einen Benutzer mit dem Namen deploy).
  2. www-data-Benutzer kann Lesezugriff auf den Laravel-Anwendungscode erhalten, nicht jedoch auf den Schreibzugriff.
  3. Um zu verhindern, dass andere Benutzer auf den Code/die Daten der Laravel-Anwendung zugreifen.
  4. Um sowohl dem www-data-Benutzer als auch dem Anwendungsbenutzer (deploy) Schreibzugriff auf den Speicherordner zu gewähren, unabhängig davon, welcher Benutzer die Datei besitzt (damit sowohl deploy als auch www-data in dieselbe Protokolldatei schreiben können).

Dies erreichen wir wie folgt:

  1. Alle Dateien im Ordner application/ werden mit der Standard-Umask von 0022 erstellt. Dies führt zu Ordnern mit drwxr-xr-x-Berechtigungen und Dateien mit -rw-r--r--.
  2. Sudo chown -R deploy:deploy application/ (oder setzen Sie Ihre Anwendung einfach als deploy-Benutzer bereit, was wir auch tun).
  3. chgrp www-data application/, um der Gruppe www-data Zugriff auf die Anwendung zu gewähren.
  4. chmod 750 application/, um dem Benutzer deploy das Lesen/Schreiben zu erlauben, dem www-data-Benutzer, der schreibgeschützt ist, und um alle Berechtigungen für andere Benutzer zu entfernen.
  5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/, um die Standardberechtigungen für den Ordner storage/ und alle Unterordner festzulegen. Alle neuen Ordner/Dateien, die im Speicherordner erstellt werden, erben diese Berechtigungen (rwx für www-data und deploy).
  6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/, um die obigen Berechtigungen für vorhandene Dateien/Ordner festzulegen.
11
Chris Schwerdt

Wie schon gepostet 

Alles, was Sie tun müssen, ist, Apache den Besitz der Ordner zu übertragen:

aber ich habe -R für chown befehl hinzugefügt: Sudo chown -R www-data:www-data /path/to/your/project/vendor Sudo chown -R www-data:www-data /path/to/your/project/storage

7

Die Laravel 5.4 docs sagen:

Nach der Installation von Laravel müssen Sie möglicherweise einige Berechtigungen konfigurieren. Verzeichnisse in den Verzeichnissen storage und bootstrap/cache Sollten von Ihrem Webserver beschreibbar sein oder Laravel wird nicht ausgeführt. Wenn Sie die virtuelle Homestead-Maschine verwenden, werden diese ausgeführt Berechtigungen sollten bereits festgelegt sein.

Es gibt viele Antworten auf dieser Seite, die die Verwendung von 777 - Berechtigungen erwähnen. Tu das nicht. Du würdest dich selbst aussetzen Hackern aussetzen.

Befolgen Sie stattdessen die Vorschläge anderer, wie Sie Berechtigungen von 755 (oder höher) festlegen. Möglicherweise müssen Sie herausfinden, unter welchem ​​Benutzer Ihre App ausgeführt wird, indem Sie whoami im Terminal ausführen und dann mit chown -R Den Besitz bestimmter Verzeichnisse ändern.

Wenn Sie nicht die Erlaubnis haben, Sudo zu verwenden, da für so viele andere Antworten Folgendes erforderlich ist ...

Ihr Server ist wahrscheinlich ein gemeinsam genutzter Host wie Cloudways.

(In meinem Fall hatte ich meine Laravel auf einen zweiten Cloudways-Server geklont, und es funktionierte nicht vollständig, da die Berechtigungen von storage und bootstrap/cache Verzeichnisse wurden durcheinander gebracht.)

Ich musste verwenden:

Cloudways Platform > Server > Application Settings > Reset Permission

Dann könnte ich php artisan cache:clear Im Terminal ausführen.

4
Ryan

Die meisten Ordner sollten "755" und Dateien "644" sein.

Laravel erfordert, dass einige Ordner für den Webserverbenutzer beschreibbar sind. Sie können diesen Befehl auf Unix-basierten Betriebssystemen verwenden.

Sudo chgrp -R www-data storage bootstrap/cache
Sudo chmod -R ug+rwx storage bootstrap/cache
4
Siddharth Joshi

Die von bgles veröffentlichte Lösung ist für mich genau richtig, wenn Sie die Berechtigungen anfangs richtig einstellen (ich verwende die zweite Methode), sie hat jedoch immer noch potenzielle Probleme für Laravel.

Standardmäßig erstellt Apache Dateien mit 644 Berechtigungen. Das ist so ziemlich alles im Speicher. Wenn Sie also den Inhalt von Storage/Framework/Views löschen und dann über Apache auf eine Seite zugreifen, werden Sie feststellen, dass die zwischengespeicherte Ansicht wie folgt erstellt wurde:

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

Wenn Sie "Artisan Serv" ausführen und auf eine andere Seite zugreifen, erhalten Sie andere 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 das keine große Sache, da Sie dies in der Produktion nicht tun werden. Wenn Apache eine Datei erstellt, die anschließend vom Benutzer geschrieben werden muss, schlägt dies fehl. Dieses kann auf Cache-Dateien, zwischengespeicherte Ansichten und Protokolle angewendet werden, wenn die Bereitstellung mit einem angemeldeten Benutzer und einem Fachmann ausgeführt wird. Ein einfaches Beispiel ist "handwerklicher Cache: löschen", der keine Cache-Dateien löschen kann, die www-data sind: www-data 644.

Dies kann teilweise gemildert werden, indem man handwerkliche Befehle als www-data ausführt, so dass man/Scripting alles wie folgt ausführt:

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 in keiner Weise die Sicherheit. Auf Entwicklungsmaschinen ist das Ausführen von Test- und Hygieneskripten jedoch unhandlich, es sei denn, Sie möchten Aliasnamen einrichten, um 'Sudo -u www-data' zum Ausführen von phpunit zu verwenden. Wenn Sie sonst Ihre Builds überprüfen, werden möglicherweise Dateien erstellt.

Die Lösung besteht darin, den zweiten Teil des Bgles-Hinweises zu befolgen und Folgendes zu/etc/Apache2/envvars hinzuzufügen und Apache neu zu starten (nicht neu zu laden):

umask 002

Dies führt dazu, dass Apache standardmäßig 664-Dateien erstellt. Dies kann an sich schon ein Sicherheitsrisiko darstellen. In den hier meist besprochenen Laravel-Umgebungen (Homestead, Vagrant, Ubuntu) wird der Webserver jedoch als Benutzer www-data unter der Gruppe www-data ausgeführt. Wenn Sie Benutzern nicht willkürlich den Beitritt zur Gruppe "www-data" gestatten, sollte kein zusätzliches Risiko entstehen. Wenn es jemandem gelingt, aus dem Webserver auszubrechen, haben sie trotzdem die www-Datenzugriffsebene, so dass nichts verloren geht (obwohl dies nicht die beste Einstellung ist, die man in Bezug auf Sicherheit zugegebenermaßen hat). In der Produktion ist das also relativ sicher und auf einer Einzelbenutzer-Entwicklungsmaschine kein Problem. 

Da sich Ihr Benutzer letztlich in der Gruppe "www-data" befindet und alle Verzeichnisse, die diese Dateien enthalten, g + s sind (die Datei wird immer unter der Gruppe des übergeordneten Verzeichnisses erstellt), werden alle vom Benutzer oder von "www-data" erstellten Dateien mit r/w für den anderen 

Und das ist das Ziel hier.

edit

Bei der Untersuchung des obigen Ansatzes zum weiteren Festlegen von Berechtigungen sieht es immer noch gut aus, aber ein paar Optimierungen können helfen:

Standardmäßig sind Verzeichnisse 775 und Dateien 664. Alle Dateien haben den Eigentümer und die Gruppe des Benutzers, der das Framework gerade installiert hat. Nehmen wir an, wir beginnen an diesem Punkt.

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

Als erstes blockieren wir den Zugang zu allen anderen und machen die Gruppe zu www-Daten. Nur der Eigentümer und 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 in der offiziellen Laravel-Installationsanleitung vorgeschlagen. Wenn Sie das Sticky-Bit der Gruppe festlegen, gehört dies dem Ersteller mit einer Gruppe von WWW-Daten.

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

Mit dem Speicherordner machen wir dasselbe, um die Erstellung von Cache-, Protokoll-, Sitzungs- und Ansichtsdateien zu ermöglichen. Wir verwenden find, um die Verzeichnisberechtigungen für Verzeichnisse und Dateien explizit anders festzulegen. Wir mussten dies nicht in bootstrap/cache tun, da dort (normalerweise) keine Unterverzeichnisse vorhanden sind.

Eventuell müssen Sie alle ausführbaren Flags erneut anwenden und Vendor/* löschen und Composer-Abhängigkeiten erneut installieren, um Verknüpfungen für phpunit et al wiederherzustellen, z. B .:

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

Das ist es. Abgesehen von dem oben erläuterten umask für Apache ist dies alles, was erforderlich ist, ohne dass die gesamte Projektwurzel durch WWW-Daten beschrieben werden kann, was bei anderen Lösungen der Fall ist. Es ist auf diese Weise geringfügig sicherer, da ein Eindringling, der als WWW-Daten ausgeführt wird, einen eingeschränkten Schreibzugriff hat.

end edit

Änderungen für Systemd

Dies gilt für die Verwendung von PHP-Fpm, aber möglicherweise auch für andere.

Der standardmäßige systemd-Dienst muss überschrieben werden, 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
3
markdwhite

Ich entschied mich dafür, mein eigenes Skript zu schreiben, um den Aufwand bei der Einrichtung von Projekten zu erleichtern. 

Führen Sie in Ihrem Projektstamm Folgendes aus:

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

Warten Sie, bis der Bootstrapping abgeschlossen ist, und Sie können loslegen.

Überprüfen Sie das Skript vor der Verwendung.

1
Jonathan

Ich habe Laravel auf der EC2-Instanz installiert und 3 Tage damit verbracht, den Erlaubnisfehler zu beheben, und schließlich den Fehler behoben ... Da möchte ich diese Erfahrung mit anderen teilen.

  1. benutzerproblem .__ Wenn ich mich in der ec2-Instanz angemeldet habe, ist mein Benutzername ec2-user und die Benutzergruppe ist ec2-user ..__ Apache.

  2. ordner- und Dateiberechtigung A. Ordnerstruktur Zuerst sollten Sie sicherstellen, dass Sie eine solche Ordnerstruktur wie diese im Speicher haben

    lager

    • rahmen
      • zwischenspeicher
      • sitzungen
      • ansichten
    • logs Die Ordnerstruktur kann je nach verwendeter Laravel-Version unterschiedlich sein Meine Laravel-Version ist 5.2 und Sie können die entsprechende Struktur entsprechend Ihrer Version finden.

B. Erlaubnis Zuerst sehe ich die Anweisungen, 777 unter Speicher zu setzen, um file_put_contents zu entfernen: Fehler beim Öffnen des Stream-Fehlers . Also habe ich die Erlaubnis 777 für die Speicherung eingerichtet. chmod -R 777 Speicher Der Fehler wurde jedoch nicht behoben. Hier sollten Sie Folgendes berücksichtigen: Wer schreibt Dateien in Speicher/Sitzungen und Ansichten . Das ist nicht ec2-user, sondern Apache . Ja richtig. Der Benutzer "Apache" schreibt die Datei (Sitzungsdatei, kompilierte Ansichtsdatei) in den Sitzungs- und Ansichtsordner . Sie sollten Apache also die Berechtigung zum Schreiben dieser Ordner erteilen. Standardmäßig: Laut SELinux sollte der Ordner/var/www vom Apache-Deamon schreibgeschützt sein.

Deshalb können wir den Selinux auf 0: .__ setzen. setenforce 0

Das kann das Problem zeitlich lösen, aber das mysql funktioniert nicht . das ist also keine so gute lösung.

Sie können einen Lese-/Schreibkontext für den Speicherordner festlegen mit: (Denken Sie an Setenforce 1, um es auszuprobieren)

chcon -Rt httpd_sys_content_rw_t storage/

Dann wird Ihr Problem behoben.

  1. und vergessen Sie nicht dieses composer update php handwerker cache: clear

    Diese Befehle werden nach oder vor nützlich sein.

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

1
Hacken Lee

Ich hatte folgende Konfiguration:

  • NGINX (laufender Benutzer: nginx)
  • PHP-FPM

Und die Berechtigungen richtig angewendet, als @bgies in der akzeptierten Antwort vorgeschlagen. Das Problem in meinem Fall war der konfigurierte laufende Benutzer und die Gruppe von php-fpm, die ursprünglich Apache war.

Wenn Sie NGINX mit php-fpm verwenden, sollten Sie die Konfigurationsdatei von php-fpm öffnen:

nano /etc/php-fpm.d/www.config

Und ersetzen Sie den Wert von user und group options mit einem NGINX, der für die Arbeit mit konfiguriert ist. in meinem Fall waren beide nginx:

... ; Unix user/group of processes ; Note: The user is mandatory. If the group is not set, the default user's group ; will be used. ; RPM: Apache Choosed to be able to access some dir as httpd user = nginx ; RPM: Keep a group allowed to write in log dir. group = nginx ...

Speichern Sie es und starten Sie die Dienste nginx und php-fpm erneut.

0
Amirreza Nasiri

Fügen Sie composer.json hinzu

"scripts": {
...
"post-install-cmd": [
      "chgrp -R www-data storage bootstrap/cache",
      "chmod -R ug+rwx storage bootstrap/cache"
    ]
...
}

Nach composer update

0
Davron Achilov