Как настроить права доступа к файлам для Laravel 5 (и других)

Разрешения для папок 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. Целью этого решения является:

• Чтобы пользователь, которому принадлежит/развертывает приложение, читает и записывает доступ к коду приложения Laravel (мы используем пользователя с именем deploy).
• Чтобы позволить пользователю www-data читать доступ к коду приложения Laravel, но не к доступу на запись.
• Чтобы другие пользователи не имели доступа к коду/данным приложения 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/ и всех подпапок. Любые новые папки/файлы, созданные в папке хранилища, наследуют эти разрешения (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-данных, поэтому вы будете делать/писать скрипты так:

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/apache 2/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-данных могут получить доступ к каталогу.

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-data, что происходит с другими решениями. Таким образом, это немного более безопасно таким образом, что злоумышленник, работающий как 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

Laravel 5.4 docs говорят:

После установки 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, а userergroup - ec2-пользователь. И сайт работает под пользователем httpd: apache: apache поэтому мы должны установить разрешение для apache.

• папка и разрешение файла Структура папки A. во-первых, вы должны убедиться, что у вас есть такая структура папок, как это в хранилище

  хранения

  • рамки
    • кэш
    • сессии
    • вид
  • журналы Структура папок может отличаться в зависимости от используемой вами версии laravel. моя версия laravel - 5.2, и вы можете найти соответствующую структуру в соответствии с вашей версией.

В. разрешение Сначала я вижу инструкции по установке 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/

Тогда ваша проблема будет исправлена.

3. и не забывайте об этом обновление композитора Кэш php artisan: clear

   Эти команды будут полезны после или раньше.

   Надеюсь, вы сэкономите свое время. Удачи. Hacken

Я решил написать свой собственный script, чтобы облегчить боль при настройке проектов.

Запустите следующее внутри корня проекта:

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

Дождитесь завершения загрузки, и вам будет хорошо.

Перед началом использования просмотрите script.

У меня была следующая конфигурация:

• NGINX (работает пользователь: nginx)
• PHP-FPM

И правильно применил разрешения, как @bgies предложил в принятом ответе. Проблема в моем случае заключалась в том, что php-fpm настроил запущенного пользователя и группу, которые изначально были apache.

Если вы используете NGINX с php-fpm, вы должны открыть файл конфигурации php-fpm:

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

И замените значение user и group опций одним NGINX, настроенным для работы; в моем случае оба были nginx:

...; Unix user/group of processes; Note: The user is mandatory. If the group is not set, the default user 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...

Сохраните его и перезапустите сервисы nginx и php-fpm.

Добавить в composer.json

"scripts": {
...
"post-install-cmd": [
      "chgrp -R www-data storage bootstrap/cache",
      "chmod -R ug+rwx storage bootstrap/cache"
    ]
...
}

После composer update

Я нашел еще лучшее решение. Это вызвано тем, что по умолчанию 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