Як налаштувати дозволи для файлів для 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. Змініть власника веб-сервера, щоб він відповідав користувачеві os (я не знаю наслідків)
4. Щось ще

Просто викласти очевидний для всіх, хто переглядає цю дискусію .... якщо ви даєте будь-якій із своїх папок 777 дозволу, ви дозволяєте ВСЕГО читати, писати та виконувати будь-який файл у цьому каталозі .... що це означає, що ви дали БУДЬ-ЯКОГО (будь-який хакер чи зловмисник у всьому світі) дозволяє завантажити будь-який файл, вірус чи будь-який інший файл, а потім виконати цей файл ...

ЯКЩО ВИ НАЛАШУВАЛІ ВАШИ ДОГОВОРИ ДЛЯ СЛУЖБИ НА 777, ВАМ ВИ НАДКРИТИ СВОЄМО СЕРВІРУ НА ВСІХ, ЩО ВИ МОЖЕТЕ ЗНАЧИТИ ЦЕ НАПРАВЛІННЯ. Досить ясно ??? :)

В основному є два способи налаштування власності та дозволів. Або ви надаєте собі право власності, або ви робите веб-сервера власником усіх файлів.

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

припустимо, що www-data (це може бути щось інше) є вашим користувачем веб-сервера.

sudo chown -R www-data: www-data / path / to / your / laravel / root / каталог

якщо ви це зробите, веб-сервер володіє всіма файлами, а також є групою, і у вас виникнуть проблеми із завантаженням файлів або роботою з файлами через 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 мій користувач: www-data / path / to / your / laravel / root / каталог

Тоді я даю і собі, і веб-серверу дозволи:

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 {} \;

Потім надайте веб-серверу права на читання та запис у сховище та кеш

Яким би способом ви його не налаштували, вам потрібно надати веб-серверу дозволи для читання і запису для зберігання, кешу та будь-яких інших каталогів, які веб-сервер повинен також завантажувати або писати (залежно від вашої ситуації), тому виконайте команди з баші вище:

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/папці створюються з умовно встановленим 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/ встановити вищезазначені дозволи на будь-які існуючі файли / папки.

Змініть дозволи для папки проекту, щоб увімкнути читання / запис / exec для будь-якого користувача в групі, що володіє каталогом (що у вашому випадку є _www):

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

Потім додайте своє ім’я користувача X 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 дозволами. Тож це майже все на зберіганні /. Отже, якщо ви видалите вміст сховища / фреймворка / переглядів, то відкрийте сторінку через 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.

Це можна частково пом'якшити, виконавши команди ремісників як 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 / 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

Дозволити веб-серверу створити services.json та compiled.php, як це запропоновано в офіційному посібнику з встановлення Laravel. Встановлення липкого біту групи означає, що їм належить творець із групою www-data.

find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage

Ми робимо те ж саме з папкою зберігання, щоб дозволити створювати кеш, журнал, сеанс та переглядати файли. Ми використовуємо find для явного встановлення дозволів для каталогу по-різному для каталогів та файлів. Нам не потрібно було це робити в завантажувальній / кеш-пам'яті, оскільки там (як правило) немає підкаталогів.

Можливо, вам знадобиться повторно застосувати будь-які виконувані прапори, видалити постачальник / * та перевстановити залежність композитора, щоб відтворити посилання для phpunit та ін, наприклад:

chmod +x .git/hooks/*
rm vendor/*
composer install -o

Це воно. За винятком поясненого вище umask для Apache, це все, що потрібно, не роблячи всю проектну кореневу програму за допомогою www-data, що саме відбувається з іншими рішеннями. Тож це гранично безпечніше таким чином, коли зловмисник, що працює як www-data, має обмежений доступ для запису.

завершити редагування

Зміни для 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, а група користувачів - користувач ec2. І веб-сайт працює під користувачем httpd користувача: apache: apache, тому ми повинні встановити дозвіл на apache.

2. дозвіл на папки та файли A. Структура папок спочатку переконайтеся, що у вас зберігається така структура папок, як ця

   зберігання

   • рамки
     • кеш
     • сеанси
     • поглядів
   • журнали Структура папок може бути різною відповідно до використовуваної версії laravel. моя версія laravel становить 5,2, і ви можете знайти відповідну структуру відповідно до вашої версії.

B. дозвіл Спочатку я бачу вказівки встановити 777 під зберігання для видалення file_put_contents: не вдалося відкрити помилку потоку. Отже, я налаштував дозвіл 777 на зберігання chmod -R 777 зберігання Але помилка не була виправлена. тут слід розглянути одне: хто записує файли у сховище / сеанси та перегляди. Це не користувач ec2, а апаш. Так правильно. Користувач "apache" записує файл (файл сесії, скомпільований файл перегляду) у сесію та переглядає папку. Тому ви повинні дати апачу написати дозвіл на цю папку. За замовчуванням: SELinux скаже, що папку / var / www повинна читати лише apache deamon.

Тож для цього ми можемо встановити selinux як 0: setenforce 0

Це може вирішити проблему тимчасово, але це робить mysql не працює. тож це не дуже вдале рішення.

Ви можете встановити контекст читання-запису в папку пам’яті за допомогою: (не забудьте посилити 1 для тестування)

chcon -Rt httpd_sys_content_rw_t storage/

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

3. і не забувайте це оновлення кеш-файлу php artisan: clear

   Ці команди будуть корисні після або раніше.

   Сподіваюся, ви заощадите свій час. Удачі. Хакен

У мене була така конфігурація:

• 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);

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

Нарешті, якщо ви використовуєте Фасад файлів у 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