Jak ustawić uprawnienia plików dla Laravel?

Uprawnienia folderów storage i vendor powinny pozostać w 775, z oczywistych względów bezpieczeństwa.

Jednak zarówno Twój komputer, jak i twój serwer Apache muszą być w stanie pisać w tych folderach. Ex: kiedy uruchamiasz polecenia takie jak php artisan, Twój komputer musi zapisywać w pliku logów w storage.

Wszystko, co musisz zrobić, to dać własność folderów Apache :

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

Następnie należy dodać swój komputer (o którym mowa username) do grupy, do której serwer Apache należy. Tak:

sudo usermod -a -G www-data userName

Uwaga: najczęściej groupName jest www-data, ale w Twoim przypadku zastąp go _www

Podczas konfigurowania uprawnień dla aplikacji Laravel napotkaliśmy wiele przypadków brzegowych. Tworzymy osobne konto użytkownika (deploy) do posiadania folderu aplikacji Laravel i wykonywania poleceń Laravel z CLI, a następnie uruchamiamy serwer WWW pod www-data. Jedną z przyczyn jest to, że pliki dziennika mogą być własnością www-data lub deploy, w zależności od tego, kto napisał do pliku dziennika jako pierwszy, co oczywiście uniemożliwia innemu użytkownikowi zapisanie go w przyszłości.

Odkryłem, że jedynym zdrowym i bezpiecznym rozwiązaniem jest użycie Linux ACLs. Celem tego rozwiązania jest:

1. aby umożliwić użytkownikowi, który posiada / wdraża aplikację dostęp do odczytu i zapisu kodu aplikacji Laravel (używamy użytkownika o nazwie deploy).
2. aby umożliwić użytkownikowi www-data dostęp do odczytu kodu aplikacji Laravel, ale nie do zapisu.
3. aby uniemożliwić innym użytkownikom dostęp do kodu/danych aplikacji Laravel.
4. aby umożliwić zarówno użytkownikowi www-data, jak i użytkownikowi aplikacji (deploy) zapisanie dostęp do folderu pamięci, niezależnie od tego, który użytkownik jest właścicielem pliku (tak więc zarówno deploy, jak i www-data mogą zapisywać na przykład do tego samego pliku dziennika).

Osiągamy to w następujący sposób:

1. wszystkie pliki w folderze application/ są tworzone z domyślną maską umask 0022, co powoduje, że foldery mają uprawnienia drwxr-xr-x, A pliki mają uprawnienia -rw-r--r--.
2. sudo chown -R deploy:deploy application/ (lub po prostu wdrożyć aplikację jako użytkownik deploy, co robimy).
3. chgrp www-data application/ aby dać www-data Grupowy dostęp do aplikacji.
4. chmod 750 application/ aby zezwolić użytkownikowi deploy Na Odczyt/Zapis, użytkownikowi www-data Tylko do odczytu oraz aby usunąć wszystkie uprawnienia innym użytkownikom.
5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/ aby ustawić domyślne prawa dostępu do folderu storage/ i wszystkich podfolderów. Wszystkie nowe foldery / pliki utworzone w folderze storage odziedziczą te uprawnienia ({[23] } zarówno dla www-data, jak i deploy).
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ aby ustawić powyższe uprawnienia dla wszystkich istniejących plików / folderów.

Zmień uprawnienia folderu projektu, aby włączyć Odczyt/Zapis / exec dla każdego użytkownika w grupie posiadającej Katalog (co w Twoim przypadku jest _www):

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

Następnie dodaj swoją nazwę użytkownika OS X do grupy _www, aby umożliwić mu dostęp do katalogu:

sudo dseditgroup -o edit -a yourusername -t user _www

To mi pomogło:

cd [..LARAVEL PROJECT ROOT]
sudo find . -type f -exec chmod 644 {} \;
sudo find . -type d -exec chmod 755 {} \;
sudo chmod -R 777 ./storage
sudo chmod -R 777 ./bootstrap/cache/

Tylko jeśli używasz npm (VUE, kompilowanie SASS, itp..) add this:

sudo chmod -R 777 ./node_modules/

Co robi:

• zmień wszystkie uprawnienia do pliku na 644
• zmień wszystkie uprawnienia folderu na 755
• dla pamięci podręcznej i bootstrap (specjalne foldery używane przez laravel do tworzenia i wykonywania plików, niedostępne z zewnątrz) Ustaw uprawnienia na 777, dla czegokolwiek wewnątrz
• dla pliku wykonywalnego nodeJS, takiego samego jak wyżej

Uwaga: Może możesz nie, lub nie trzeba, aby to zrobić z prefiksem sudo. to zależy od uprawnień użytkownika, grupy, itp...

Większość folderów powinna być normalna " 755 " i pliki "644"

Laravel wymaga, aby niektóre foldery były zapisywalne dla użytkownika serwera www. Możesz użyć tego polecenia w systemie oss opartym na Uniksie.

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

Dodaj do composer.json

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

Po composer install

As posted already

Wszystko, co musisz zrobić, to dać własność folderów Apache :

Ale dodałem -R dla chown polecenie: sudo chown -R www-data:www-data /path/to/your/project/vendor sudo chown -R www-data:www-data /path/to/your/project/storage

The Laravel 5.4 docs say:

Po zainstalowaniu Laravel może być konieczne skonfigurowanie niektórych uprawnień. Katalogi w katalogach storage i bootstrap/cache powinien być zapisywalny przez serwer WWW lub Laravel nie będzie działać. Jeśli korzystają z maszyny Wirtualnej Homestead, uprawnienia te powinny już gotowe.

Na tej stronie jest wiele odpowiedzi, które wspominają o używaniu 777 uprawnień. Nie rób tego. byłabyś ujawnienie się hakerom.

Zamiast tego postępuj zgodnie z sugestiami innych, jak ustawić uprawnienia 755 (lub bardziej restrykcyjne). Być może będziesz musiał dowiedzieć się, który użytkownik jest uruchomiony przez Twoją aplikację, uruchamiając whoami w terminalu, a następnie zmienić własność niektórych katalogów za pomocą chown -R.

Jeśli nie masz uprawnień do używania sudo, tak jak wymaga tego wiele innych odpowiedzi...

Twój serwer jest prawdopodobnie współdzielonym hostem, takim jak Cloudways.

(W moim przypadek, sklonowałem moją aplikację Laravel do drugiego mojego serwera Cloudways i nie działało całkowicie, ponieważ uprawnienia katalogów storage i bootstrap/cache były popsute.)

Potrzebowałem użyć:

Cloudways Platform > Server > Application Settings > Reset Permission

Wtedy mógłbym uruchomić php artisan cache:clear w terminalu.

Rozwiązanie opublikowane przez bgles jest dla mnie na miejscu pod względem poprawnego ustawienia uprawnień na początku( używam drugiej metody), ale nadal ma potencjalne problemy z Laravel.

Domyślnie Apache tworzy pliki z uprawnieniami 644. Więc to prawie wszystko w magazynie/. Tak więc, jeśli usuniesz zawartość storage / framework/views, a następnie uzyskasz dostęp do strony za pośrednictwem Apache, zobaczysz, że widok w pamięci podręcznej został utworzony w następujący sposób:

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

Jeśli uruchomisz "artisan serve" i dostęp do innej strony, otrzymasz różne uprawnienia, ponieważ CLI PHP zachowuje się inaczej niż Apache:

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

Można to częściowo złagodzić, uruchamiając polecenia artisan jako www-data, więc będziesz robić / skryptować wszystko, jak:

sudo -u www-data php artisan cache:clear

Albo unikniesz żmudności tego i dodasz to do swojego .bash_aliases:

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

umask 002

Spowoduje to, że Apache domyślnie utworzy pliki jako 664. Samo w sobie może to stanowić zagrożenie dla bezpieczeństwa. Jednak w środowiskach Laravel głównie omawianych tutaj (Homestead, Vagrant, Ubuntu) serwer WWW działa jako użytkownik www-data w grupie www-data. Więc jeśli nie arbitralnie pozwalają użytkownikom dołączyć do grupy www-data, nie powinno być żadnego dodatkowego ryzyka. Jeśli komuś uda się wyrwać z serwera, to i tak ma dostęp do danych www, więc nic nie jest stracone (choć nie jest to najlepsze podejście do bezpieczeństwa). Tak więc na produkcji jest stosunkowo bezpieczny, a na maszynie programistycznej dla jednego użytkownika nie jest to po prostu problem.

Ostatecznie jako użytkownik znajduje się w grupie www-data, a wszystkie katalogi zawierające te pliki to g + s (plik jest zawsze tworzony pod grupą katalogu nadrzędnego), wszystko utworzone przez użytkownika lub przez www-data będzie r/W dla drugiego.

I to jest cel tutaj.

edytuj

Po zbadaniu powyższego podejścia do ustawiania uprawnień, nadal wygląda to wystarczająco dobrze, ale kilka poprawek może pomóc:

Domyślnie, katalogi to 775, A Pliki to 664, a wszystkie pliki mają właściciela i grupy użytkowników, którzy właśnie zainstalowali framework. Więc załóżmy, że zaczniemy od tego punktu.

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

Pierwszą rzeczą, którą robimy, to zablokowanie dostępu do wszystkich innych i uczynienie grupy www-data. Tylko właściciel i członkowie www-data mogą uzyskać dostęp do katalogu.

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

Aby umożliwić serwerowi tworzenie usług.JSON i skompilowany.php, zgodnie z sugestią oficjalnego przewodnika instalacji Laravela. Ustawienie grupy sticky bit oznacza, że będą one własnością twórcy z grupą www-data.

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

Robimy to samo z folderem storage, aby umożliwić tworzenie plików pamięci podręcznej, dziennika, sesji i widoku. Używamy find, aby jawnie ustawić uprawnienia do katalogów w inny sposób dla katalogów i plików. Nie musieliśmy tego robić w bootstrap/cache, ponieważ nie ma tam (normalnie) żadnych podkatalogów.

Może być konieczne ponowne użycie FLAG wykonywalnych, usunięcie vendor/ * i ponowne zainstalowanie zależności composera, aby odtworzyć linki do phpunit i innych, eg:

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

To jest to. Z wyjątkiem umask dla Apache wyjaśnione powyżej, jest to wszystko, co jest wymagane bez tworzenia całego projektu zapisywalny przez www-data, co dzieje się z innymi rozwiązaniami. Jest to więc nieco bezpieczniejsze, ponieważ Intruz działający jako www-data ma bardziej ograniczony dostęp do zapisu.

koniec edycji

zmiany dla Systemd

Dotyczy to użycia php-fpm, ale może inne też.

Standardowa Usługa systemd musi zostać nadpisana, umask ustawiony w nadpisaniu.plik conf, a usługa uruchomiona ponownie:

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

Postanowiłem napisać własny scenariusz, aby złagodzić ból związany z tworzeniem projektów.

Uruchom następujące elementy wewnątrz katalogu głównego projektu:

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

Poczekaj na zakończenie bootstrapowania i możesz zaczynać.

Przejrzyj skrypt przed użyciem.

Zainstalowałem laravel na instancji EC2 i spędziłem 3 dni, aby naprawić błąd uprawnień i w końcu go naprawić. Chcę więc podzielić się tym doświadczeniem z innymi.

1. Problem użytkownika Kiedy zalogowałem się w instancji ec2, moja nazwa użytkownika to EC2-user, a grupa użytkowników to ec2-user. A strona działa pod adresem httpd user: apache: apache więc powinniśmy ustawić pozwolenie na apache.

2. Uprawnienia do folderu i Pliku A. Struktura folderów po pierwsze, należy upewnić się, że mieć taką strukturę folderów jak ta pod storage

   Przechowywanie

   • framework
     • cache
     • sesje
     • views
   • logi Struktura folderów może się różnić w zależności od używanej wersji laravel. moja wersja laravel to 5.2 i możesz znaleźć odpowiednią strukturę zgodnie z twoją wersją.

B. pozwolenie Na początku widzę instrukcje, aby ustawić 777 pod magazynem, aby usunąć file_put_contents: failed aby otworzyć błąd strumienia. Więc ustawiłem pozwolenie 777 na przechowywanie chmod-R 777 storage Ale błąd nie został naprawiony. tutaj należy wziąć pod uwagę jeden: kto pisze pliki do storage / sessions i views. To nie jest ec2-user, ale apache. Tak, racja. użytkownik "apache" zapisuje plik (plik sesji, skompilowany plik widoku) do folderu session I view. Powinieneś więc dać apache ' owi uprawnienia do zapisu do tych folderów. Domyślnie: SELinux mówi, że folder / var / www powinien być tylko do odczytu przez apache deamon.

Więc w tym celu możemy ustawić selinux jako 0: setenforce 0

To może rozwiązać problem tymczasowo, ale to sprawia, że mysql nie działa. więc to nie jest tak dobre rozwiązanie.

Możesz ustawić kontekst odczytu i zapisu do folderu pamięci za pomocą: (pamiętaj, aby ustawić setenforce 1, aby go przetestować)

chcon -Rt httpd_sys_content_rw_t storage/

Wtedy twój problem zostanie rozwiązany.

1. I nie zapomnij o tym composer update PHP artisan cache: clear

   Polecenia te będą przydatne po lub wcześniej.

   Mam nadzieję, że zaoszczędzisz swój czas. Powodzenia. Hacken

Miałem następującą konfigurację:

• NGINX (running user: nginx)
• PHP-FPM

I poprawnie zastosował uprawnienia Zgodnie z sugestią @bgies w zaakceptowanej odpowiedzi. Problem w moim przypadku był skonfigurowany przez PHP-fpm uruchomiony użytkownik i grupa, która pierwotnie była apache.

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

... ; 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 ...

Zapisz go i uruchom ponownie usługi nginx i php-fpm.

Dla programistów Laravel problemy z katalogami mogą być trochę uciążliwe. W mojej aplikacji tworzyłem katalogi w locie i z powodzeniem przenosiłem pliki do tego katalogu w moim środowisku lokalnym. Następnie na serwerze otrzymywałem błędy podczas przenoszenia plików do nowo utworzonego katalogu.

Oto rzeczy, które zrobiłem i uzyskałem udany wynik na końcu.

1. sudo find /path/to/your/laravel/root/directory -type f -exec chmod 664 {} \;
sudo find /path/to/your/laravel/root/directory -type d -exec chmod 775 {} \;
2. chcon -Rt httpd_sys_content_rw_t /path/to/my/file/upload/directory/in/laravel/project/
3. podczas tworzenia nowego katalogu w locie, użyłem polecenie mkdir($save_path, 0755, true);

Po wprowadzeniu tych zmian na serwerze produkcyjnym z powodzeniem utworzyłem nowe katalogi i przeniosłem do nich pliki.

Wreszcie, jeśli używasz File facade w Laravel możesz zrobić coś takiego: File::makeDirectory($save_path, 0755, true);

Pierwsza odpowiedź brzmi:

sudo chmod -R 777/775 /path/project_folder

Teraz musisz zrozumieć uprawnienia i opcje w ubuntu.

• chmod - możesz ustawić uprawnienia.
• chown - możesz ustawić własność plików i katalogów.
• 777 - Odczyt/Zapis/wykonanie.
• 775 - read/execute.

Zrobiłbym to tak:

sudo chown -R $USER:www-data laravel-project/ 

find laravel-project/ -type f -exec chmod 664 {} \;

find laravel-project/ -type d -exec chmod 775 {} \;

Następnie musisz dać webserverowi pozwolenie na modyfikację katalogów storage i bootstrap/cache:

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

Znalazłem na to jeszcze lepsze rozwiązanie. Jest to spowodowane tym, że php domyślnie działa jako inny użytkownik.

Więc naprawić to zrobić

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

Następnie Edytuj user = "put user that owns the directories" group = "put user that owns the directories"

Wtedy:

sudo systemctl reload php7.0-fpm