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
777to zbyt duża swoboda, ponieważ obejmuje wszystkie uprawnienia dla wszystkich.