it-swarm.com.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

предполагая, что www-data (это может быть что-то еще) является вашим пользователем веб-сервера.

    Судо чоун -R www-данные: 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 хранилище начальной загрузки/кеша

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

376
bgies

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

36
BassMHL

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

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

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

Sudo dseditgroup -o edit -a yourusername -t user _www
12
Bogdan

Мы столкнулись со многими случаями Edge при настройке разрешений для приложений 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/ создаются с 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 только для чтения и удалить все разрешения для любых других пользователей.
  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/ для установки вышеуказанных разрешений для любых существующих файлов/папок.
11
Chris Schwerdt

Как уже опубликовано 

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

но я добавил -R for chown command: Sudo chown -R www-data:www-data /path/to/your/project/vendor Sudo chown -R www-data:www-data /path/to/your/project/storage

7
Stanislav Potapenko

Большинство папок должны быть обычными "755" и файлами "644"

Laravel требует, чтобы некоторые папки были доступны для записи пользователю веб-сервера. Вы можете использовать эту команду на ОС Unix.

Sudo chgrp -R www-data storage bootstrap/cache
Sudo chmod -R ug+rwx storage bootstrap/cache
4
Siddharth Joshi

Решение, опубликованное 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, описанного выше, это все, что требуется, не делая весь корень проекта доступным для записи с помощью 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
3
markdwhite

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 в терминале.

2
Ryan

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

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

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

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

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

1
Jonathan

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

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

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

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

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

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

Поэтому для этого мы можем установить selinux равным 0: Сетенфорс 0

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

Вы можете установить контекст чтения-записи в папку хранилища с помощью: (не забудьте набрать 1 для проверки)

chcon -Rt httpd_sys_content_rw_t storage/

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

  1. и не забудьте об этом Обновление композитора PHP кеш ремесленника: очистить

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

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

1
Hacken Lee

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

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

0
Amirreza Nasiri

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

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

После composer update

0
Davron Achilov