Как настроить права доступа к файлам для Laravel?

Я использую веб-сервер Apache, для которого установлен владелец _www:_www. Я никогда не знаю, что лучше всего делать с правами доступа к файлам, например, когда я создаю новый проект Laravel 5.

Laravel 5 требует, чтобы /storageпапка была доступна для записи. Я нашел много разных подходов, чтобы заставить это работать, и я обычно заканчиваю делать это 777chmod рекурсивно. Я знаю, что это не лучшая идея.

Официальный документ говорит:

Laravel может потребовать настройки некоторых разрешений: папок внутри storageи vendorдоступа к записи через веб-сервер.

Означает ли это , что веб - сервер должен иметь доступ к storageи vendorсами папки тоже или только их текущее содержание?

Я предполагаю, что, что намного лучше, это смена владельца вместо разрешения. Я рекурсивно изменил все права доступа к файлам Laravel, _www:_wwwи сайт стал работать правильно, как будто я изменил chmod на 777. Проблема в том, что теперь мой текстовый редактор запрашивает у меня пароль каждый раз, когда я хочу сохранить какой-либо файл, и то же самое происходит, если я пытаюсь что-то изменить в Finder, например, скопировать файл.

Как правильно подходить к решению этих проблем?

1. + Изменить chmod
2. Измените владельца файлов так, чтобы он соответствовал владельцам веб-сервера, и, возможно, настройте текстовый редактор (и Finder?), Чтобы пропустить запрос пароля или заставить их использовать sudo
3. Изменить владельца веб-сервера в соответствии с пользователем ОС (я не знаю, последствия)
4. Что-то другое

Просто констатирую очевидное для любого, кто просматривает это обсуждение ... если вы дадите 777 разрешений для любой из ваших папок, вы позволите ЛЮБОМ прочитать, записать и выполнить любой файл в этом каталоге ... что это означает, что вы дали ЛЮБОМУ (любому хакеру или злоумышленнику во всем мире) разрешению загружать ЛЮБОЙ файл, вирус или любой другой файл, и ТОГДА выполнять этот файл ...

ЕСЛИ ВЫ УСТАНАВЛИВАЕТЕ НАШИ ПАПКИ РАЗРЕШЕНИЯ НА 777, ВЫ ОТКРЫЛИ СВОЙ СЕРВЕР ДЛЯ ТОГО, ЧТО МОЖЕТ НАЙТИ ЭТУ ДИРЕКТОРИЮ. Достаточно ясно??? :)

Есть два основных способа настройки вашего владельца и прав доступа. Либо вы предоставляете себе право собственности, либо вы делаете веб-сервер владельцем всех файлов.

Веб-сервер как владелец (как большинство людей делают это, и способ документа Laravel):

предполагая, что 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 ... УСТАНОВИТЬ разрешения для файлов

sudo find / path / to / your / laravel / root / directory -type f -exec chmod 644 {} \;    

УСТАНОВИТЬ разрешения каталога

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 / laravel / root / directory -type d -exec chmod 775 {} \;

Затем дайте веб-серверу права на чтение и запись в хранилище и кеш

Каким бы способом вы ни настроили его, вам нужно дать разрешения на чтение и запись для веб-сервера для хранения, кэширования и любых других каталогов, которые веб-сервер должен также загружать или записывать (в зависимости от вашей ситуации), поэтому выполните команды из bashy выше:

sudo chgrp -R www-хранилище данных начальная загрузка / кеш
sudo chmod -R ug + rwx хранилище начальной загрузки / кеш

Теперь вы в безопасности и ваш сайт работает, и вы можете работать с файлами довольно легко

Разрешения для 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

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

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

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

Мы выполняем это следующим образом:

1. Все файлы в application/папке создаются с использованием маски по умолчанию 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для чтения, и удалить все разрешения для любых других пользователей.
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/ установить вышеуказанные разрешения для любых существующих файлов / папок.

Измените разрешения для папки вашего проекта, чтобы включить чтение / запись / exec для любого пользователя в группе, владеющей каталогом (в вашем случае это _www):

chmod -R 775 /path/to/your/project

Затем добавьте свое имя пользователя OS X в _wwwгруппу, чтобы разрешить ему доступ к каталогу:

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

Как уже выложили

Все, что вам нужно сделать, это передать права доступа к папкам 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

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

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

После composer install

Документы Laravel 5.4 гласят:

После установки 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в терминал.

Решение, опубликованное 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

Это сработало для меня:

cd [..LARAVEL PROJECT ROOT]
sudo find . -type f -exec chmod 644 {} \;
sudo find . -type d -exec chmod 755 {} \;
sudo chmod -R 777 ./storage
sudo chmod -R 777 ./bootstrap/cache/

Что оно делает:

• Измените все права доступа к файлу на 644
• Измените все разрешения для папок на 755
• Для хранилища и загрузочного кэша (специальные папки, используемые laravel для создания и выполнения файлов, недоступные извне) установите разрешение 777 для всего, что находится внутри

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

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

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

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

Подождите, пока начнется загрузка, и все готово.

Просмотрите сценарий перед использованием.

Я установил laravel на экземпляр EC2 и потратил 3 дня, чтобы исправить ошибку разрешения и наконец исправил ее. Поэтому я хочу поделиться этим опытом с другим.

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

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

   место хранения

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

B. Разрешение Сначала я вижу инструкции по установке 777 под хранилище для удаления file_put_contents: не удалось открыть поток ошибок. Поэтому я настроил разрешение 777 для хранилища chmod -R 777 storage Но ошибка не была исправлена. Здесь вы должны рассмотреть один: кто записывает файлы в хранилище / сеансы и представления. Это не 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 cache: clear

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

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

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

• 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's 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.

Для разработчиков Laravel проблемы с каталогами могут быть немного болезненными. В моем приложении я создавал каталоги на лету и успешно перемещал файлы в этот каталог в моей локальной среде. Затем на сервере я получал ошибки при перемещении файлов во вновь созданный каталог.

Вот то, что я сделал и получил успешный результат в конце.

1. sudo find /path/to/your/laravel/root/directory -type f -exec chmod 664 {} \;
sudo find /path/to/your/laravel/root/directory -type d -exec chmod 775 {} \;
2. chcon -Rt httpd_sys_content_rw_t /path/to/my/file/upload/directory/in/laravel/project/
3. При создании нового каталога на лету я использовал команду mkdir($save_path, 0755, true);

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

Наконец, если вы используете File фасад в Laravel, вы можете сделать что-то вроде этого: File::makeDirectory($save_path, 0755, true);

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