Jak skonfigurować uprawnienia do plików dla Laravel?

Używam serwera WWW Apache, którego właściciel ma ustawioną wartość _www:_www. Nigdy nie wiem, jaka jest najlepsza praktyka z uprawnieniami do plików, na przykład kiedy tworzę nowy projekt Laravel 5.

Laravel 5 wymaga, /storageaby folder był zapisywalny. Znalazłem wiele różnych podejść, aby to działało i zwykle kończę na 777rekursywnym chmod. Wiem, że to nie najlepszy pomysł.

Oficjalny dokument mówi:

Laravel może wymagać skonfigurowania niektórych uprawnień: folderów wewnątrz storagei vendorwymaga dostępu do zapisu przez serwer WWW.

Czy to oznacza, że ​​serwer WWW potrzebuje również dostępu do samych folderów storagei vendorczy tylko ich bieżącej zawartości?

Zakładam, że o wiele lepiej jest zmieniać właściciela zamiast uprawnień. Zmieniłem rekursywnie wszystkie uprawnienia do plików Laravela _www:_wwwi dzięki temu strona działała poprawnie, tak jakbym zmienił chmod na 777. Problem polega na tym, że teraz mój edytor tekstowy prosi mnie o hasło za każdym razem, gdy chcę zapisać dowolny plik, i to samo dzieje się, gdy próbuję zmienić cokolwiek w Finderze, na przykład skopiować plik.

Jakie jest właściwe podejście do rozwiązania tych problemów?

1. Zmiana chmod
2. Zmień właściciela plików, aby pasowały do ​​plików na serwerze internetowym, i może ustaw edytor tekstu (i Finder?), Aby pomijał pytanie o hasło, lub użyj ich sudo
3. Zmień właściciela serwera WWW, aby pasował do użytkownika systemu operacyjnego (nie znam konsekwencji)
4. Coś innego

Wystarczy powiedzieć oczywiste dla każdego, kto przegląda tę dyskusję ... jeśli udzielisz któregoś z folderów uprawnień 777, zezwalasz KAŻDEMU na odczyt, zapis i wykonanie dowolnego pliku w tym katalogu .... co to znaczy, że dałeś KAŻDY (dowolny haker lub złośliwa osoba na całym świecie) uprawnienie do przesłania DOWOLNEGO pliku, wirusa lub innego pliku, a NASTĘPNIE wykonanie tego pliku ...

JEŚLI USTAWISZ SWOJE UPRAWNIENIA DO FOLDERU DO 777, OTWORZYŁEŚ SWOJEGO SERWERA DLA KAŻDEGO, KTÓRY MOGĄ ZNALEŹĆ TEN KATALOG. Wystarczająco jasne ??? :)

Istnieją zasadniczo dwa sposoby konfiguracji własności i uprawnień. Albo dasz sobie prawo własności, albo uczynisz serwer WWW właścicielem wszystkich plików.

Webserver jako właściciel (sposób, w jaki robi to większość ludzi, i sposób doktora Laravela):

zakładając, że www-data (może być czymś innym) jest twoim użytkownikiem serwera.

sudo chown -R www-data: www-data / path / to / your / laravel / root / directory

jeśli to zrobisz, serwer WWW jest właścicielem wszystkich plików, a także jest grupą, i będziesz mieć problemy z przesyłaniem plików lub pracą z plikami za pośrednictwem FTP, ponieważ klient FTP będzie zalogowany jako Ty, a nie serwer WWW, więc dodaj Twój użytkownik do grupy użytkowników serwera WWW:

sudo usermod -a -G www-data ubuntu

Oczywiście zakłada to, że twój serwer działa jako www-data (domyślny Homestead), a twoim użytkownikiem jest ubuntu (jest to błędne, jeśli używasz Homestead).

Następnie ustaw wszystkie katalogi na 755, a pliki na 644 ... USTAW uprawnienia do plików

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

Ustaw uprawnienia do katalogu

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

Twój użytkownik jako właściciel

Wolę mieć wszystkie katalogi i pliki (to znacznie ułatwia pracę ze wszystkim), więc robię:

sudo chown -R mój-użytkownik: www-data / path / to / your / laravel / root / directory

Następnie daję zarówno sobie, jak i serwerowi sieciowemu uprawnienia:

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 {} \;

Następnie daj serwerowi sieciowemu prawo do odczytu i zapisu w pamięci i pamięci podręcznej

Niezależnie od tego, w jaki sposób go skonfigurujesz, musisz dać serwerowi uprawnienia do odczytu i zapisu w celu przechowywania, buforowania i innych katalogów, które serwer musi przesyłać lub zapisywać (w zależności od sytuacji), więc uruchom polecenia z nieśmiałego powyżej:

sudo chgrp -R www-data bootstrap / cache
sudo chmod -R ug + rwx pamięć bootstrap / cache

Teraz jesteś bezpieczny, a Twoja witryna działa, I możesz dość łatwo pracować z plikami

Z oczywistych względów bezpieczeństwa uprawnienia do folderów storagei vendorpowinny pozostać 775.

Jednak zarówno komputer, jak i serwer Apache muszą mieć możliwość pisania w tych folderach. Np .: kiedy uruchamiasz takie polecenia php artisan, komputer musi zapisać plik dziennika w storage.

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

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 musisz dodać swój komputer (do którego się odwołuje username) do grupy, do której należy serwer Apache. Tak jak:

sudo usermod -a -G www-data userName

UWAGA: Najczęściej groupNamejest, www-dataale w twoim przypadku zamień go na_www

Podczas konfigurowania uprawnień dla aplikacji Laravel napotkaliśmy wiele przypadków. Tworzymy osobne konto użytkownika ( deploy) do posiadania folderu aplikacji Laravel i wykonywania poleceń Laravel z poziomu interfejsu CLI i uruchamiania serwera WWW pod www-data. Jednym z problemów jest to, że plik (i) dziennika mogą być własnością www-datalub deploy, w zależności od tego, kto napisał do pliku dziennika, co oczywiście uniemożliwia innemu użytkownikowi zapisywanie w nim w przyszłości.

Odkryłem, że jedynym rozsądnym i bezpiecznym rozwiązaniem jest korzystanie z list ACL systemu Linux. Celem tego rozwiązania jest:

1. Aby umożliwić użytkownikowi, który jest właścicielem / wdraża aplikację, dostęp do odczytu i zapisu do kodu aplikacji Laravel (korzystamy z nazwy użytkownika deploy).
2. Aby umożliwić www-dataużytkownikowi dostęp do odczytu kodu aplikacji Laravel, ale nie dostęp do zapisu.
3. Aby w ogóle uniemożliwić innym użytkownikom dostęp do kodu / danych aplikacji Laravel.
4. Aby zezwolić zarówno www-dataużytkownikowi, jak i aplikacji ( deploy) na dostęp do zapisu do folderu pamięci, niezależnie od tego, który użytkownik jest właścicielem pliku (na przykład zarówno deployi www-datamoże zapisywać do tego samego pliku dziennika).

Dokonujemy tego w następujący sposób:

1. Wszystkie pliki w application/folderze są tworzone z domyślną umaską 0022, co powoduje, że foldery mają drwxr-xr-xuprawnienia i pliki -rw-r--r--.
2. sudo chown -R deploy:deploy application/(lub po prostu wdrożyć aplikację jako deployużytkownik, co robimy).
3. chgrp www-data application/aby dać www-datagrupie dostęp do aplikacji.
4. chmod 750 application/aby zezwolić deployużytkownikowi na odczyt / zapis, na www-dataużytkownika tylko do odczytu oraz na usunięcie wszystkich uprawnień dla innych użytkowników.
5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/aby ustawić domyślne uprawnienia do storage/folderu i wszystkich podfolderów. Wszelkie nowe foldery / pliki utworzone w folderze przechowywania odziedziczą te uprawnienia ( rwxzarówno dla, jak www-datai dla deploy).
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ aby ustawić powyższe uprawnienia dla dowolnych istniejących plików / folderów.

Zmień uprawnienia do folderu projektu, aby umożliwić odczyt / zapis / wykonanie dla dowolnego użytkownika w grupie będącej właścicielem katalogu (w twoim przypadku jest to _www):

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

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

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

Jak już napisano

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

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

Większość folderów powinna mieć normalne „755”, a pliki „644”

Laravel wymaga, aby niektóre foldery były zapisywalne dla użytkownika serwera WWW. Możesz użyć tego polecenia w systemach operacyjnych opartych 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

Dokumenty Laravel 5.4 mówią:

Po zainstalowaniu Laravela może być konieczne skonfigurowanie niektórych uprawnień. Katalogi wewnątrz storagei bootstrap/cachekatalogi powinny być zapisywane przez twój serwer WWW, inaczej Laravel nie będzie działał. Jeśli używasz maszyny wirtualnej Homestead, uprawnienia te powinny być już ustawione.

Na tej stronie znajduje się wiele odpowiedzi, które wspominają o korzystaniu z 777uprawnień. Nie rób tego Byłbyś narażając się na ataki hakerów.

Zamiast tego postępuj zgodnie z sugestiami innych osób, jak ustawić uprawnienia 755 (lub bardziej restrykcyjne). Może być konieczne whoamiustalenie, z jakiego użytkownika korzysta Twoja aplikacja, uruchamiając ją w terminalu, a następnie zmienić właściciela niektórych katalogów chown -R.

Jeśli nie masz uprawnień do korzystania, sudoponieważ wiele innych odpowiedzi wymaga ...

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

(W moim przypadku sklonowałem moją aplikację Laravel na moim drugim serwerze Cloudways i nie działała ona całkowicie, ponieważ uprawnienia storagei bootstrap/cachekatalogi zostały zawalone).

Musiałem użyć:

Cloudways Platform > Server > Application Settings > Reset Permission

Wtedy mógłbym biec php artisan cache:clearw terminalu.

Rozwiązanie opublikowane przez bgles jest dla mnie na miejscu, jeśli chodzi o prawidłowe ustawianie uprawnień na początku (używam drugiej metody), ale nadal ma potencjalne problemy dla Laravela.

Domyślnie Apache tworzy pliki z uprawnieniami 644. Więc to prawie wszystko w pamięci. Jeśli więc usuniesz zawartość pamięci / frameworka / widoków, a następnie wejdziesz na stronę przez Apache, zobaczysz, że buforowany widok 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 „serwis rzemieślnika” i uzyskasz 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

Samo w sobie to nie jest wielka sprawa, ponieważ nie zrobisz tego w produkcji. Ale jeśli Apache utworzy plik, który następnie musi zostać zapisany przez użytkownika, zakończy się niepowodzeniem. I to może dotyczyć plików pamięci podręcznej, buforowanych widoków i dzienników podczas wdrażania przy użyciu zalogowanego użytkownika i rzemieślnika. Łatwym przykładem jest „rzemieślnicza pamięć podręczna: wyczyść”, która nie usunie żadnych plików pamięci podręcznej, które są www-data: www-data 644.

Można to częściowo złagodzić, uruchamiając polecenia rzemieślnika jako dane www, więc będziesz robił / skrypty takie jak:

sudo -u www-data php artisan cache:clear

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

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

Jest to wystarczająco dobre i nie wpływa w żaden sposób na bezpieczeństwo. Ale na komputerach programistycznych uruchamianie skryptów testowych i sanitarnych sprawia, że ​​jest to niewygodne, chyba że chcesz skonfigurować aliasy do korzystania z 'sudo -u www-data' do uruchamiania phpunit i wszystkiego, co sprawdzasz w swoich kompilacjach, co może powodować tworzenie plików.

Rozwiązaniem jest postępowanie zgodnie z drugą częścią porady bgles i dodanie następujących poleceń do / etc / apache2 / envvars i ponowne uruchomienie (nie przeładowywanie) Apache:

umask 002

Zmusi to Apache do domyślnego tworzenia plików jako 664. Samo w sobie może to stanowić zagrożenie bezpieczeństwa. Jednak w środowiskach Laravel, które są tutaj omawiane (Homestead, Vagrant, Ubuntu), serwer WWW działa jako użytkownik www-data w grupie www-data. Jeśli więc nie zezwolisz arbitralnie użytkownikom na dołączenie do grupy danych www, nie powinno być dodatkowego ryzyka. Jeśli komuś uda się wydostać z serwera, i tak ma on poziom dostępu do danych www, więc nic nie jest stracone (choć nie jest to najlepsze podejście do bezpieczeństwa). Tak więc w produkcji jest względnie bezpieczny, a na maszynie programistycznej dla jednego użytkownika nie stanowi to problemu.

Ostatecznie, ponieważ użytkownik znajduje się w grupie danych www, a wszystkie katalogi zawierające te pliki to g + s (plik jest zawsze tworzony w grupie katalogu nadrzędnego), wszystko, co utworzy użytkownik lub dane www, będzie miało postać r / w dla drugiego.

I to jest cel tutaj.

edytować

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

Domyślnie katalogi to 775, a pliki 664, a wszystkie pliki mają właściciela i grupę użytkownika, który właśnie zainstalował platformę. Załóżmy więc, że zaczynamy od tego momentu.

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

Pierwszą rzeczą, którą robimy, jest blokowanie dostępu do wszystkich innych i sprawienie, aby grupa była danymi www. 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 zezwolić serwerowi WWW na tworzenie services.json i compiled.php, zgodnie z oficjalnym przewodnikiem instalacji Laravela. Ustawienie bitu lepkiego grupy oznacza, że ​​będzie on własnością twórcy z grupą danych www.

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 przechowywania, aby umożliwić tworzenie plików pamięci podręcznej, dziennika, sesji i przeglądania. Używamy find do jawnego ustawiania uprawnień katalogu inaczej dla katalogów i plików. Nie musieliśmy tego robić w bootstrap / cache, ponieważ nie ma (normalnie) żadnych podkatalogów.

Może być konieczne ponowne zastosowanie wszystkich flag wykonywalnych, usunięcie dostawcy / * i ponowne zainstalowanie zależności kompozytora, aby odtworzyć łącza do phpunit i in., Np .:

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

Otóż ​​to. Z wyjątkiem wyjaśnionego powyżej umask dla Apache, to wszystko, co jest wymagane, bez konieczności zapisywania całego projektu do zapisu przez www-data, co dzieje się w przypadku innych rozwiązań. Jest więc w ten sposób marginalnie bezpieczniejszy, ponieważ intruz działający jako www-data ma bardziej ograniczony dostęp do zapisu.

zakończ edycję

Zmiany w Systemd

Dotyczy to korzystania z php-fpm, ale może także innych.

Standardowa usługa systemowa musi zostać zastąpiona, umask ustawiony w pliku override.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

To działało dla mnie:

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/

Co to robi:

• Zmień wszystkie uprawnienia do plików na 644
• Zmień wszystkie uprawnienia do folderów na 755
• W przypadku pamięci podręcznej i pamięci podręcznej bootstrap (specjalne foldery używane przez laravel do tworzenia i wykonywania plików, niedostępne z zewnątrz) należy ustawić uprawnienie na 777 dla wszystkich elementów wewnątrz

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

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

Uruchom następujące elementy w katalogu głównym projektu:

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

Poczekaj na zakończenie ładowania początkowego i możesz zacząć.

Przejrzyj skrypt przed użyciem.

Zainstalowałem laravel na instancji EC2 i spędziłem 3 dni, aby naprawić błąd pozwolenia i wreszcie go naprawiłem. Chcę więc podzielić się tym doświadczeniem z innym.

1. problem użytkownika Gdy loguję się do instancji ec2, moja nazwa użytkownika to ec2-user, a grupa użytkowników to ec2-user. Witryna działa pod adresem użytkownika httpd: apache: apache, więc powinniśmy ustawić zezwolenie na apache.

2. uprawnienia do folderów i plików A. struktura folderów w pierwszej kolejności, należy upewnić się, że taka struktura folderów jest taka jak w magazynie

   przechowywanie

   • struktura
     • Pamięć podręczna
     • sesje
     • wyświetlenia
   • logi Struktura folderów może być różna w zależności od używanej wersji laravel. moja wersja laravel to 5.2 i możesz znaleźć odpowiednią strukturę zgodnie ze swoją wersją.

B. pozwolenie Najpierw widzę instrukcje, aby ustawić 777 w pamięci, aby usunąć file_put_contents: nie udało się otworzyć błędu strumienia. Więc skonfigurowałem uprawnienia 777 do przechowywania chmod -R 777 Storage Ale błąd nie został naprawiony. tutaj powinieneś rozważyć jedno: kto zapisuje pliki w pamięci / sesjach i widokach. To nie jest użytkownik ec2, ale apache. Tak, racja. Użytkownik „apache” zapisuje plik (plik sesji, skompilowany plik widoku) do folderu sesji i widoku. Powinieneś więc dać Apache'owi prawo zapisu do tego folderu. Domyślnie: SELinux twierdzi, że folder / var / www powinien być tylko do odczytu przez demon apache.

W tym celu możemy ustawić selinux na 0: setenforce 0

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

Możesz ustawić kontekst odczytu / zapisu w folderze przechowywania za pomocą: (pamiętaj o ustawieniu 1, aby go przetestować)

chcon -Rt httpd_sys_content_rw_t storage/

Twój problem zostanie naprawiony.

3. i nie zapomnij tej pamięci podręcznej aktualizacji php rzemieślnika: wyczyść

   Te polecenia będą przydatne po lub przed.

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

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

• Nginx (bieganie, użytkownik: nginx)
• PHP-FPM

I zastosował uprawnienia poprawnie, jak @bgies sugeruje w zaakceptowanej odpowiedzi. Problemem w moim przypadku był skonfigurowany działający użytkownik i grupa php-fpm, który był pierwotnie apache.

Jeśli używasz NGINX z php-fpm, powinieneś otworzyć plik konfiguracyjny php-fpm:

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

A wartość zamiany useri groupopcji jednym NGINX jest skonfigurowana do pracy; w moim przypadku oba były 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 ...

Zapisz i zrestartuj usługi nginx i php-fpm.

Dla deweloperów Laravela problemy z katalogiem mogą być nieco uciążliwe. W mojej aplikacji tworzyłem katalogi w locie i pomyślnie przenosiłem pliki do tego katalogu w moim lokalnym środowisku. Potem na serwerze pojawiały się błędy podczas przenoszenia plików do nowo utworzonego katalogu.

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

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 polecenia mkdir($save_path, 0755, true);

Po wprowadzeniu tych zmian na serwerze produkcyjnym udało mi się utworzyć nowe katalogi i przenieść do nich pliki.

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

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

więc aby to naprawić, zrób to

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"

następnie:

sudo systemctl reload php7.0-fpm