Uprawnienia do plików dla Laravel 5 (i innych)
Używam serwera Apache, który ma właściciela ustawionego na _www:_www
. Nigdy nie wiem, jaka jest najlepsza praktyka z uprawnieniami do plików, na przykład podczas tworzenia nowego projektu Laravel 5.
Laravel 5 wymaga folderu /storage
do zapisu. Znalazłem wiele różnych podejść, aby to działało i zwykle kończę na tym, że robię to rekurencyjnie 777
chmod. Wiem, że to nie jest najlepszy pomysł.
Oficjalny lekarz mówi:
Laravel może wymagać pewnych uprawnień konfiguracja: foldery wewnątrz
storage
ivendor
wymagają dostępu do zapisu przez serwer WWW.
Czy to znaczy, że serwer WWW potrzebuje dostępu do samych folderów storage
i vendor
czy tylko ich bieżącej zawartości?
Zakładam, że to, co jest dużo lepsze, to zmiana właściciela zamiast uprawnień. Zmieniłem rekurencyjnie uprawnienia wszystkich plików Laravela na _www:_www
i to sprawiło, że strona działała poprawnie, tak jakbym zmienił chmod na 777
. Problem w tym, że teraz moja edytor tekstu pyta mnie o hasło za każdym razem, gdy chcę zapisać plik i to samo dzieje się, jeśli próbuję coś zmienić w Finderze, na przykład skopiować plik.
Jakie jest najbardziej popularne podejście do rozwiązywania tych problemów?
- Zmień
chmod
- Zmień właściciela plików, aby pasował do tych z
serwer WWW i może ustawić edytor tekstu (i Finder?) aby pominąć
Prośba o hasło lub ich użycie
sudo
- Zmień właściciela serwera www na dopasuj użytkownika os (nie poznaj konsekwencje)
- Something else
12 answers
Aby stwierdzić oczywistość dla każdego, kto ogląda tę dyskusję.... jeśli nadasz któremuś z folderów 777 uprawnienia, zezwalasz każdemu na odczyt, zapis i wykonanie dowolnego pliku w tym katalogu.... oznacza to, że dałeś każdemu (hakerowi lub złośliwej osobie na całym świecie) pozwolenie na przesłanie dowolnego pliku, wirusa lub innego pliku, a następnie wykonanie tego pliku...
JEŚLI USTAWIASZ UPRAWNIENIA FOLDERU NA 777, OTWORZYŁEŚ SWÓJ SERWER DLA KAŻDEGO, KTO MOGĘ ZNALEŹĆ TEN KATALOG. Jasne??? :)
Istnieją zasadniczo dwa sposoby skonfigurowania własności i uprawnień. Albo dajesz sobie prawo własności, albo sprawiasz, że serwer internetowy jest właścicielem wszystkich plików.
Webserver jako właściciel (tak jak większość ludzi to robi):
Zakładając, że www-data jest Twoim użytkownikiem serwera www.
sudo chown -R www-data:www-data /path/to/your/laravel/root/directory
Jeśli to zrobisz, serwer jest właścicielem wszystkich plików, a także jest grupą, i będziesz miał pewne problemy z załadowaniem plików lub praca z plikami przez FTP, ponieważ klient FTP będzie zalogowany jako ty, a nie twój serwer, więc Dodaj użytkownika do grupy użytkowników serwera: {]}
sudo usermod -a -G www-data ubuntu
Oczywiście zakłada to, że twój serwer WWW działa jako www-data (domyślnie Homestead), a Twoim użytkownikiem jest ubuntu (jest to vagrant, jeśli używasz Homestead).
Następnie ustawiasz wszystkie katalogi na 755, a pliki na 644... SET file permissions
sudo find /path/to/your/laravel/root/directory -type f -exec chmod 644 {} \;
Ustaw uprawnienia katalogu
sudo find /path/to/your/laravel/root/directory -type d -exec chmod 755 {} \;
Twój użytkownik jako właściciel
Wolę posiadać wszystkie katalogi i pliki (to znacznie ułatwia pracę ze wszystkim), więc robię:
sudo chown -R my-user:www-data /path/to/your/laravel/root/directory
Następnie daję zarówno sobie, jak i serwerowi 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 nadaj serwerowi prawa do odczytu i zapisu do storage and cache
Niezależnie od tego, w jaki sposób go skonfigurujesz, musisz nadać serwerowi www uprawnienia do odczytu i zapisu w celu przechowywania, pamięci podręcznej i innych katalogów, które serwer WWW musi przesłać lub zapisać (w zależności od sytuacji), więc uruchom polecenia z bashy powyżej:
sudo chgrp -R www-data storage bootstrap/cache sudo chmod -R ug+rwx storage bootstrap/cache
Teraz jesteś bezpieczny i Twoja strona działa, i możesz pracować z plikami dość łatwo
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-09-14 22:42:13
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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-07-19 19:15:17
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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-06-04 09:18:27
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:
- 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
). - aby umożliwić użytkownikowi
www-data
dostęp do odczytu kodu aplikacji Laravel, ale nie do zapisu. - aby uniemożliwić innym użytkownikom dostęp do kodu/danych aplikacji Laravel.
- 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ównodeploy
, jak iwww-data
mogą zapisywać na przykład do tego samego pliku dziennika).
Osiągamy to w następujący sposób:
- wszystkie pliki w folderze
application/
są tworzone z domyślną maską umask0022
, co powoduje, że foldery mają uprawnieniadrwxr-xr-x
, A pliki mają uprawnienia-rw-r--r--
. -
sudo chown -R deploy:deploy application/
(lub po prostu wdrożyć aplikację jako użytkownikdeploy
, co robimy). -
chgrp www-data application/
aby daćwww-data
Grupowy dostęp do aplikacji. -
chmod 750 application/
aby zezwolić użytkownikowideploy
Na Odczyt/Zapis, użytkownikowiwww-data
Tylko do odczytu oraz aby usunąć wszystkie uprawnienia innym użytkownikom. -
setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/
aby ustawić domyślne prawa dostępu do folderustorage/
i wszystkich podfolderów. Wszystkie nowe foldery / pliki utworzone w folderze storage odziedziczą te uprawnienia ({[23] } zarówno dlawww-data
, jak ideploy
). -
setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/
aby ustawić powyższe uprawnienia dla wszystkich istniejących plików / folderów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-12-21 17:11:55
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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-06-01 15:49:01
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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-06-06 11:40:10
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
Sama w sobie nie jest to nic wielkiego, ponieważ nie będziesz robił tego w produkcji. Ale jeśli Apache utworzy plik, który następnie musi być napisany przez użytkownika, to się nie powiedzie. I to Może stosować się do 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 "artisan cache: clear", który nie usunie wszelkie pliki pamięci podręcznej, które są www-data:www-data 644.
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'
Jest to wystarczająco dobre i w żaden sposób nie wpływa na bezpieczeństwo. Ale na maszynach programistycznych uruchamianie skryptów testowych i sanitarnych sprawia, że jest to nieporęczne, chyba że chcesz skonfigurować aliasy do używania ' sudo-u www-data ' aby uruchomić phpunit i wszystko inne można sprawdzić swoje buildy, które mogą spowodować pliki do tworzenia.
W związku z tym, że nie jest to możliwe, nie jest to konieczne, ponieważ nie jest to konieczne, ponieważ nie jest to konieczne.]}
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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-11-15 04:02:18
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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-03-10 22:43:27
The Laravel 5.4 docs say:
Po zainstalowaniu Laravel może być konieczne skonfigurowanie niektórych uprawnień. Katalogi w katalogach
storage
ibootstrap/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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-26 21:35:32
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.
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.
-
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ą.
- framework
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.
-
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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-07-15 10:47:32
Dodaj do composer.json
"scripts": {
...
"post-update-cmd": [
"chmod -R 777 storage",
"chmod -R 775 bootstrap/cache",
"chmod 775 vendor"
]
...
}
Po composer update
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-10-09 10:07:46
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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-10-18 23:56:35