Я использую веб-сервер Apache, у которого владелец установлен на _www:_www . Я никогда не знаю, что лучше всего подходит для прав доступа к файлам, например, когда я создаю новый проект Laravel 5.
Laravel 5 требует, чтобы папка /storage доступна для записи. Я нашел много разных подходов, чтобы заставить его работать, и я обычно заканчиваю его рекурсией 777 chmod. Я знаю, что это не лучшая идея.
В официальном документе говорится:
Laravel может потребовать настройки некоторых разрешений: папки в
storageиvendorтребуют доступа на запись веб-сервером.
Означает ли это, что веб-серверу нужен доступ к самим storage и папкам vendor или только к их текущему содержимому?
Я предполагаю, что гораздо лучше, вместо владельца, вместо владельца . Я изменил все разрешения на файлы Laravel рекурсивно на _www:_www и это заставило сайт работать правильно, как если бы я изменил chmod на 777 . Проблема в том, что теперь мой текстовый редактор запрашивает у меня пароль каждый раз, когда я хочу сохранить любой файл, и то же самое происходит, если я попытаюсь что-то изменить в Finder, например, скопировать файл.
Какой самый популярный подход для решения этих проблем?
chmod sudo Просто чтобы указать очевидное для любого, кто смотрит эту дискуссию …. если вы даете какие-либо из ваших папок 777 разрешений, вы разрешаете ANYONE читать, записывать и выполнять любые файлы в этом каталоге … что это означает, что вы дали ANYONE (любой хакер или злоумышленник во всем мире) разрешает загружать ЛЮБОЙ файл, вирус или любой другой файл, а THEN выполняет этот файл …
ЕСЛИ ВЫ УСТАНАВЛИВАЕТЕ РАЗРЕШЕНИЕ ВАШИХ ПАКЕТОВ К 777, ВЫ ОТКРЫВАЕТЕ ВАШЕГО СЕРВЕРА ЛЮБОЙ, КОТОРЫЙ МОЖЕТ НАЙТИ ЭТО СПИСОК. Достаточно ясно??? 🙂
Есть два способа настроить ваше право собственности и разрешения. Либо вы даете себе право собственности, либо вы делаете веб-сервер владельцем всех файлов.
Веб-сервер как владелец (как это делают большинство людей):
предполагая, что www-data – ваш пользователь веб-сервера.
sudo chown -R www-data: www-data / path / to / your / laravel / root / directory
если вы это сделаете, веб-сервер будет владеть всеми файлами, а также группой, и у вас возникнут проблемы с загрузкой файлов или работой с файлами через FTP, потому что ваш FTP-клиент будет зарегистрирован как вы, а не ваш веб-сервер, поэтому добавьте ваш пользователь в группу пользователей веб-сервера:
sudo usermod -a -G www-data ubuntu
Конечно, это предполагает, что ваш веб-сервер работает как www-data (по умолчанию Homestead), а ваш пользователь – ubuntu (он бродяжнее, если вы используете Homestead).
Затем вы установите все свои каталоги на 755 и ваши файлы на 644 … Разрешения файла SET
sudo find / path / to / your / laravel / root / directory -type f -exec chmod 644 {} \;
Разрешения каталога SET
sudo find / path / to / your / laravel / root / directory -type d -exec chmod 755 {} \;
Ваш пользователь как владелец
Я предпочитаю владеть всеми каталогами и файлами (это облегчает работу со всем), поэтому я делаю:
sudo chown -R my-user: www-data / path / to / your / laravel / root / directory
Затем я предоставляю как себя, так и разрешения веб-сервера:
sudo find / path / to / your / laravel / root / directory -type f -exec chmod 664 {} \;
sudo find / path / to / your / root / directory -type d -exec chmod 775 {} \;
Затем дайте веб-серверу права на чтение и запись в хранилище и кеш
Каким бы способом вы его не настроили, вам необходимо предоставить разрешения на чтение и запись на веб-сервер для хранения, кеширования и любых других каталогов, которые веб-серверу необходимо загрузить или написать тоже (в зависимости от вашей ситуации), поэтому запустите команды из bashy выше:
sudo chgrp -R www-data bootstrap / cache sudo chmod -R ug + rwx storage bootstrap / cache
Теперь вы защищены и ваш сайт работает, И вы можете работать с файлами довольно легко
Разрешения для папок storage и vendor должны оставаться на уровне 775 по очевидным соображениям безопасности.
Однако, как ваш компьютер, так и ваш сервер Apache должны иметь возможность писать в этих папках. Например: когда вы запускаете команды, такие как php artisan , ваш компьютер должен записывать в файл журналов на storage .
Все, что вам нужно сделать, это передать права доступа к папкам 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
Затем вам нужно добавить свой компьютер (по его username ) в группу, к которой принадлежит сервер Apache. Вот так :
sudo usermod -a -G www-data userName
ПРИМЕЧАНИЕ. Чаще всего groupName является www-data но в вашем случае замените его на _www
Измените разрешения для своей папки проекта, чтобы включить чтение / запись / exec для любого пользователя в группе, владеющей каталогом (которая в вашем случае равна _www ):
chmod -R 775 /path/to/your/project
Затем добавьте свое имя пользователя OS X в группу _www чтобы разрешить ему доступ к каталогу:
sudo dseditgroup -o edit -a yourusername -t user _www
При настройке разрешений для приложений Laravel мы сталкиваемся со многими крайними случаями. Мы создаем отдельную учетную запись пользователя ( deploy ) для владения папкой приложения Laravel и выполнения команд Laravel из CLI и запуска веб-сервера по www-data . Одна из проблем заключается в том, что файл (ы) журнала могут принадлежать www-data или deploy , в зависимости от того, кто первым написал файл журнала, что явно не позволяет другому пользователю писать в будущем.
Я обнаружил, что единственным разумным и безопасным решением является использование списков ACL Linux. Целью этого решения является:
deploy ). www-data читать доступ к коду приложения Laravel, но не к доступу на запись. www-data пользователю приложения ( deploy ) записывать доступ к папке хранилища, независимо от того, какой пользователь владеет этим файлом (так, например, как deploy и www-data могут записываться в один и тот же файл журнала). Мы выполняем это следующим образом:
application/ папке создаются с использованием по умолчанию umask 0022 , что приводит к папкам с drwxr-xr-x и файлами, имеющими -rw-r--r-- . sudo chown -R deploy:deploy application/ (или просто развернуть приложение как пользователь deploy , что и мы). chgrp www-data application/ чтобы предоставить группе www-data доступ к приложению. chmod 750 application/ разрешить deploy пользователя для чтения / записи, пользователя www-data доступного только для чтения, и удалить все разрешения для других пользователей. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/ для установки разрешений по умолчанию storage/ папки storage/ папки и всех подпапок. Любые новые папки / файлы, созданные в папке хранилища, наследуют эти разрешения ( rwx для www-data и deploy ). setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ для установки вышеуказанных разрешений на любые существующие файлы / папки. Как уже было опубликовано
Все, что вам нужно сделать, это передать права доступа к папкам Apache:
но я добавил -R для команды 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
Большинство папок должны быть нормальными «755» и файлами «644»,
Laravel требует, чтобы некоторые папки были доступны для записи для пользователя веб-сервера. Вы можете использовать эту команду для ОС на основе unix.
sudo chgrp -R www-data storage bootstrap/cache sudo chmod -R ug+rwx storage bootstrap/cache
Решение, отправленное bgles, для меня доступно с точки зрения правильной установки разрешений изначально (я использую второй метод), но у него все еще есть потенциальные проблемы для Laravel.
По умолчанию Apache будет создавать файлы с 644 правами доступа. Так что это почти что угодно в хранилище /. Таким образом, если вы удалите содержимое хранилища / фреймворка / представления, то доступ к странице через 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-данными: 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-данными. Поэтому, если вы не произвольно разрешаете пользователям вступать в группу www-data, не должно быть никаких дополнительных рисков. Если кому-то удастся вырваться из веб-сервера, у них есть уровень доступа к www-данным, так что ничего не потеряно (хотя это не лучшее отношение к тому, чтобы иметь отношение к безопасности, по общему признанию). Так что в производстве это относительно безопасно, и на однопользовательской машине разработки это просто не проблема.
В конечном счете, поскольку ваш пользователь находится в группе www-data, и все каталоги, содержащие эти файлы, являются g + s (файл всегда создается под группой родительского каталога), все, созданное пользователем или www-данными, будет r / w для другого.
И это цель здесь.
редактировать
Изучив вышеприведенный подход к настройке разрешений, он по-прежнему выглядит достаточно хорошо, но несколько настроек могут помочь:
По умолчанию каталоги составляют 775, а файлы – 664, а во всех файлах есть владелец и группа пользователей, которые только что установили фреймворк. Поэтому предположим, что мы начинаем с этого момента.
cd /var/www/projectroot sudo chmod 750 ./ sudo chgrp www-data ./
Первое, что мы делаем, это блокировать доступ ко всем остальным и сделать группу www-данными. Доступ к каталогу может получить только владелец и члены www-data.
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, чтобы явно устанавливать разрешения на каталоги по-разному для каталогов и файлов. Нам не нужно было делать это в bootstrap / cache, так как нет (обычно) любых подкаталогов.
Возможно, вам придется повторно применить любые исполняемые флаги и удалить поставщика / * и повторно установить зависимости композитора для воссоздания ссылок для phpunit и др., Например:
chmod +x .git/hooks/* rm vendor/* composer install -o
Вот и все. За исключением рассмотренного выше umask для Apache, это все, что требуется, без того, чтобы весь проект был написан по www-данным, что происходит с другими решениями. Таким образом, это более безопасно таким образом, что злоумышленник, работающий как www-data, имеет более ограниченный доступ на запись.
end edit
Изменения для 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
Я решил написать свой собственный сценарий, чтобы облегчить боль при создании проектов.
Выполните следующее внутри корня проекта:
wget -qO- https://raw.githubusercontent.com/defaye/bootstrap-laravel/master/bootstrap.sh | sh
Подождите, пока начнется загрузка, и вам будет хорошо.
Просмотрите сценарий перед использованием.
После установки Laravel вам может потребоваться настроить некоторые разрешения. Каталоги в
storageи каталогиbootstrap/cacheдолжны быть доступны для записи на вашем веб-сервере или Laravel не будет запускаться. Если вы используете виртуальную машину Homestead, эти разрешения уже должны быть установлены.
На этой странице есть много ответов, в которых упоминается использование 777 разрешений. Не делай этого. Вы будете подвергать себя хакерам.
Вместо этого следуйте рекомендациям других о том, как устанавливать разрешения 755 (или более ограничительные). Возможно, вам придется выяснить, какой пользователь работает в вашем приложении, как запустить whoami в терминале, а затем изменить право собственности на определенные каталоги с помощью chown -R .
sudo так как требуется много других ответов … Возможно, ваш сервер является общим хостом, таким как Cloudways.
(В моем случае я клонировал свое приложение Laravel на второй сервер Cloudways, и он не был полностью работоспособен, потому что права на каталоги storage и bootstrap/cache были испорчены).
Мне нужно было использовать:
Cloudways Platform > Server > Application Settings > Reset Permission
Затем я мог запустить php artisan cache:clear терминал.
Я установил laravel на экземпляр EC2 и потратил 3 дня на исправление ошибки разрешения и, наконец, исправил его. Поэтому я хочу поделиться этим опытом с другим.
проблема пользователя. Когда я вошел в экземпляр ec2, мое имя пользователя – ec2-user, а пользовательская группа – ec2-пользователь. И сайт работает под httpd user: apache: apache, поэтому мы должны установить разрешение для apache.
папка и файл A. Сначала создайте структуру папок, вы должны убедиться, что у вас такая структура папок, как эта, в хранилище
место хранения
B. Разрешение. Сначала я вижу инструкции по установке 777 под хранилищем для удаления file_put_contents: не удалось открыть ошибку потока. Поэтому я установил разрешение 777 на хранилище chmod -R 777, но ошибка не была исправлена. здесь вы должны рассмотреть один: кто пишет файлы для хранения / сеансов и представлений. Это не ec2-пользователь, а apache. Да, верно. Пользователь «apache» записывает файл (файл сеанса, скомпилированный файл просмотра) в папку сеанса и просмотра. Поэтому вы должны предоставить apache для записи разрешения на эту папку. По умолчанию: SELinux говорит, что папка / var / www должна быть доступна только для чтения от apache deamon.
Поэтому для этого мы можем установить selinux как 0: setenforce 0
Это может решить проблему временно, но это делает mysql неработоспособным. поэтому это не очень хорошее решение.
Вы можете установить контекст чтения и записи в папку хранилища с помощью: (не забудьте отключить 1, чтобы проверить его)
chcon -Rt httpd_sys_content_rw_t storage/
Тогда ваша проблема будет исправлена.
и не забывайте, что этот сборщик обновления php artisan cache: clear
Эти команды будут полезны после или раньше.
Надеюсь, вы сэкономите свое время. Удачи. Hacken
Я нашел еще лучшее решение. Это вызвано тем, что по умолчанию php работает как другой пользователь.
поэтому исправить это сделать
sudo nano /etc/php/7.0/fpm/pool.d/www.conf
затем отредактируйте user = "put user that owns the directories" group = "put user that owns the directories"
тогда:
sudo systemctl reload php7.0-fpm