Решение, опубликованное bgles, предназначено для меня с точки зрения правильной настройки разрешений изначально (я использую второй метод), но оно все еще имеет потенциальные проблемы для Laravel.
По умолчанию Apache создает файлы с разрешениями 644. Так что это почти все в хранилище /. Итак, если вы удалите содержимое хранилища / framework / views, а затем зайдя на страницу через Apache, вы обнаружите, что кэшированное представление было создано следующим образом:
-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2
Если вы запустите «artisan serve» и получите доступ к другой странице, вы получите другие разрешения, потому что CLI PHP ведет себя иначе, чем Apache:
-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e
Само по себе это не имеет большого значения, так как вы не будете делать ничего этого на производстве. Но если Apache создает файл, который впоследствии должен быть записан пользователем, он потерпит неудачу. И это может применяться к файлам кэша, кэшированным представлениям и журналам при развертывании с использованием зарегистрированного пользователя и ремесленника. Легким примером является «Кэш ремесленника: очистить», который не удалит любые файлы кеша, которые являются www-data: www-data 644.
Это может быть частично смягчено запуском команд artisan как www-data, так что вы будете делать / писать все что угодно:
sudo -u www-data php artisan cache:clear
Или вы избежите утомительности этого и добавите это к своим .bash_aliases:
alias art='sudo -u www-data php artisan'
Это достаточно хорошо и никак не влияет на безопасность. Но на машинах разработки запуск сценариев тестирования и санитарии делает это громоздким, если только вы не хотите настроить псевдонимы для использования sudo -u www-data для запуска phpunit и всего остального, с чем вы проверяете свои сборки, что может привести к созданию файлов.
Решение состоит в том, чтобы следовать второй части совета bgles, добавить следующее в / etc / apache2 / envvars и перезапустить (не перезагружать) Apache:
umask 002
Это заставит Apache создавать файлы как 664 по умолчанию. Само по себе это может представлять угрозу безопасности. Однако в средах Laravel, которые в основном обсуждаются здесь (Homestead, Vagrant, Ubuntu), веб-сервер работает как пользовательские www-данные в группе www-data. Поэтому, если вы не разрешаете пользователям произвольно присоединяться к группе www-данных, дополнительного риска быть не должно. Если кому-то удастся вырваться из веб-сервера, у него все равно будет уровень доступа к www-данным, так что ничего не будет потеряно (хотя, по общему признанию, это не лучшее отношение к безопасности). Так что на производстве это относительно безопасно, а на однопользовательской машине разработки это не проблема.
В конечном итоге, поскольку ваш пользователь находится в группе www-данных, и все каталоги, содержащие эти файлы, являются g + s (файл всегда создается в группе родительского каталога), все, что создано пользователем или www-data, будет r / ж для другого.
И это цель здесь.
редактировать
Изучив описанный выше подход к дальнейшей настройке разрешений, он все еще выглядит достаточно хорошо, но может помочь несколько настроек:
По умолчанию каталогов 775 и файлов 664, и все файлы имеют владельца и группу пользователей, которые только что установили платформу. Итак, предположим, что мы начнем с этого момента.
cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./
Первое, что мы делаем, это блокируем доступ ко всем остальным и делаем группу доступной для www-данных. Только владелец и члены www-данных могут получить доступ к каталогу.
sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache
Разрешить веб-серверу создавать services.json и compiled.php в соответствии с официальным руководством по установке Laravel. Установка бита закрепления группы означает, что он будет принадлежать создателю с группой www-данных.
find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage
Мы делаем то же самое с папкой хранения, чтобы разрешить создание кэша, журнала, сессии и просмотра файлов. Мы используем find, чтобы явно установить права доступа к каталогам для каталогов и файлов. Нам не нужно было делать это в начальной загрузке / кэше, поскольку там нет (обычно) никаких подкаталогов.
Вам может понадобиться повторно применить любые исполняемые флаги, удалить vendor / * и переустановить зависимости composer, чтобы воссоздать ссылки для phpunit et al, например:
chmod +x .git/hooks/*
rm vendor/*
composer install -o
Вот и все. За исключением umask для Apache, описанного выше, это все, что требуется, без необходимости делать весь root-файл доступным для записи с помощью www-данных, как это происходит с другими решениями. Таким образом, это немного безопаснее, поскольку злоумышленник, работающий с www-данными, имеет более ограниченный доступ для записи.
конец редактирования
Изменения для Systemd
Это относится и к использованию php-fpm, но, возможно, и к другим.
Стандартную службу systemd необходимо переопределить, установить umask в файле override.conf и перезапустить службу:
sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service
777это слишком большая свобода, потому что она включает в себя все разрешения для всех.