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

разрешения storage и vendor папки должны остаться в 775, по понятным причинам безопасности.

однако и ваш компьютер, и ваш сервер Apache должны иметь возможность писать в этих папках. Пример: при выполнении команд типа php artisan, ваш компьютер должен записать в файл журналов в storage.

все, что вам нужно сделать, это дать право собственности на папки Апача :

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 group, чтобы разрешить ему доступ к каталогу:

sudo dseditgroup -o edit -a yourusername -t user _www

мы столкнулись со многими крайними случаями при настройке разрешений для приложений Laravel. Мы создаем отдельную учетную запись (deploy) для владения папкой приложения Laravel и выполнения команд Laravel из CLI и запуска веб-сервера под www-data. Одна из проблем заключается в том, что файл(ы) журнала может принадлежать www-data или deploy, в зависимости от того, кто написал в файл журнала первым, очевидно, не позволяя другому пользователю писать в него в будущем.

я нашел что единственным разумным и безопасным решением является использование Linux ACLs. Цель этого решения:

1. чтобы разрешить пользователю, который владеет / развертывает приложение, доступ для чтения и записи кода приложения Laravel (мы используем пользователя с именем deploy).
2. разрешить www-data доступ пользователя для чтения кода приложения Laravel, но не для записи.
3. чтобы запретить другим пользователям доступ к коду/данным приложения Laravel вообще.
4. чтобы разрешить the www-data пользователь и пользователь приложения (deploy) запись доступа к папке хранения, независимо от того, какой пользователь владеет файлом (так что оба deploy и www-data можно писать в тот же файл журнала, например).

мы делаем это следующим образом:

1. все файлы внутри application/ папка создается с umask по умолчанию 0022, в результате чего папки имеют drwxr-xr-x разрешения и файлы -rw-r--r--.
2. sudo chown -R deploy:deploy application/ (или просто разверните приложение как deploy пользователей, что мы и делаем).
3. chgrp www-data application/ дать www-data групповой доступ к приложению.
4. chmod 750 application/ разрешить deploy чтение/запись пользователя,www-data user только для чтения и удалить все разрешения для любых других пользователей.
5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/ установить права по умолчанию на storage/ папка и все подпапки. Любые новые папки/файлы, созданные в папке хранения, унаследуют эти разрешения (rwx как www-data и deploy).
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ чтобы установить вышеуказанные разрешения для любых существующих файлов / папок.

Как написал уже

все, что вам нужно сделать, это дать право собственности на папки Апача :

но я добавил - R на Чаун : 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-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 среды в основном обсуждаются здесь (Усадьба, Бродяга, Ubuntu) веб-сервер работает как пользователь www-data в группе www-data. Поэтому, если вы произвольно не разрешаете пользователям присоединяться к группе www-data, дополнительного риска быть не должно. Если кому-то удается вырваться из веб-сервера, у них все равно есть уровень доступа к данным www, поэтому ничего не теряется (хотя это не лучшее отношение к безопасности). Так на продукции относительно безопасно, и на однопользовательской машине развития, это просто не проблема.

в конечном счете, поскольку ваш пользователь находится в группе www-data, а все каталоги, содержащие эти файлы, являются g+s (файл всегда создается в группе родительского каталога), все, что создано пользователем или www-data, будет r/w для другого.

и это цель здесь.

редактировать

при исследовании вышеуказанного подхода к настройке разрешений дальше, он по-прежнему выглядит хорошо достаточно, но несколько настроек могут помочь:

по умолчанию каталоги 775, а файлы 664, и все файлы имеют владельца и группу пользователя, который только что установил фреймворк. Предположим, мы начнем с этого момента.

cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./

Первое, что мы делаем, это заблокировать доступ ко всем остальным и сделать группу www-data. Только владелец и члены www-data могут получить доступ к каталогу.

sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache

чтобы сервер создать услуги.json и составленный.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

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

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

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

дождитесь завершения начальной загрузки, и вы можете идти.

обзор скрипта перед использованием.

на 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 дня, чтобы исправить ошибку разрешения и, наконец, исправил ее. Поэтому я хочу поделиться этим опытом с другим.

1. проблемы пользователей Когда я вошел в экземпляр ec2, мое имя пользователя ec2-user и usergroup-ec2-user. И сайт работает под httpd пользователя: apache: apache поэтому мы должны установить разрешение для apache.

2. разрешение папки и файла А. структура папок во-первых, вы следует убедиться, что у вас есть такая структура папок, как это в разделе storage

   для хранения

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

разрешения Б. На во-первых, я вижу инструкции по установке 777 в хранилище для удаления file_put_contents: не удалось открыть ошибку потока. Поэтому я настраиваю разрешение 777 на хранение команду chmod -Р хранения 777 Но ошибка не была исправлена. здесь вы должны рассмотреть один: кто записывает файлы в хранилище / сеансы и представления. Это не ec2-пользователь, а apache. Да, конечно. пользователь "apache" записывает файл (файл сеанса, скомпилированный файл представления) в папку сеанса и представления. Поэтому вы должны дать apache разрешение на запись в эту папку. От по умолчанию: SELinux говорит, что папка /var/www должна быть доступна только для чтения apache deamon.

поэтому для этого мы можем установить selinux как 0: setenforce 0

Это может решить проблему временно, но это делает MySQL не работает. так что это не очень хорошее решение.

вы можете установить контекст чтения-записи в папку хранения с: (не забудьте setenforce 1, чтобы проверить его)

chcon -Rt httpd_sys_content_rw_t storage/

тогда ваша проблема будет зафиксированный.

1. и не забывайте, что это обновление композитор php artisan кэш: очистить

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

   надеюсь, вы сэкономите свое время. Удача. Хакен!--2-->

добавить в composer.в JSON

"scripts": {
...
"post-update-cmd": [
      "chmod -R 777 storage",
      "chmod -R 775 bootstrap/cache",
      "chmod 775 vendor"
    ]
...
}

после 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