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


235

Я использую веб-сервер 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. Что-то другое

4
Я думаю, что 777это слишком большая свобода, потому что она включает в себя все разрешения для всех.
Робо Робок

Из документов Laravel: каталоги внутри storageи bootstrap/cacheкаталоги должны быть доступны для записи на вашем веб-сервере
joshuamabina

1
используйте fcgi, и вы можете 755/644 для всех (включая public / storage)
Jeffz

@jww согласен, можем ли мы перенести вопрос на сервер, вместо того чтобы поставить его на удержание?
wp78de

Ответы:


589

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

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


4
Отличный пример, если нет пользователя www-data, используйте apache: apache вместо www-данных (на некоторых дистрибутивах)
Денис Солакович,

53
Я думаю, что люди неправильно понимают эту anyoneконцепцию. anyoneФлаг Linux означает любого пользователя , а не любого человека. Вам все еще нужен доступ к серверу.
Марко Аурелио Делё

3
@ andreshg112 Первые www-данные - это имя пользователя, а вторые www-данные - это имя группы. Таким образом, это означает, что владелец apache и (this-group) apache. Используйте www-data: www-data или добавьте своего пользователя в эту группу. (CLI: useradd -G {
имя_группы

2
@fs_tigre Я не думаю, что для безопасности вообще есть какая-то разница ... за исключением того, что я предполагаю, что есть два пользователя, для которых нужно угадать пароли вместо одного, и, конечно, я все время захожу в систему со своей учетной записью, поэтому Я сделал это небезопасным способом (обычный FTP и, например, используя пароль), это могло поставить под угрозу сайт, но я входил только через Putty и SSH, а когда я использую FTP, это SFTP, так что никаких проблем вообще нет. Команды, предложенные bashy, рекомендуются, потому что они устанавливают бит закрепления, поэтому, если ваш веб-сервер создает подкаталоги, они будут иметь того же владельца / разрешения, что и родительский
bgies

3
При первом способе пользователь не сможет загрузить файлы, поскольку вы не дали writeразрешение группе?
Фахми

44

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


11
+1 Мне нравится такой подход. Но я считаю, что chownкоманды должны включать флаг -R. Кроме того, в laravel 5.1 и 5.2 вместо каталога vendor вы должны предоставить доступ к каталогу bootstrap / cache.
Джейсон Уилер

Есть ли способ проверить, будет ли это работать нормально? Я имею в виду, если новый файл журнала будет создан в директории storage / logs, у которого будут правильные разрешения, как я могу это проверить?
Чаудхри Вакас

20

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

15

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

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

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

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

Когда я , dseditgroupпредоставленный вами, я получаю сообщение об ошибке: Username and password must be provided..
Робо Робок

Моя ошибка, вам нужно запустить эту команду с пользователем, у которого есть соответствующие разрешения, так что просто добавьте sudoв начале.
Богдан

Так что мне нужно сменить владельца этих файлов _www:_wwwили myuser:_wwwтоже?
Робо Робок

Вы можете оставить его _www:_www, потому что 775 означает, что любой пользователь в группе _wwwбудет иметь полные права на чтение / запись / редактирование в этой папке, и вы просто добавили свое имя пользователя в эту группу.
Богдан

Не могли бы вы сказать мне одну вещь? Что это значит chown myuser:_www? Я знаю, что первый - это пользователь, а второй - это группа, но означает ли это «этот пользователь и кто-либо из этой группы» или «этот пользователь, но только если он принадлежит этой группе»?
Робо Робок

8

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

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


3
Почему мы должны дать разрешение на каталог продавца? Хранение имеет смысл, для записи в лог-файлы и т. Д. Но вендор? Зачем?
Али Харис

Как написано выше в некоторых комментариях: «Тем не менее, и ваш компьютер, и ваш сервер Apache должны иметь возможность писать в эти папки. Например: когда вы запускаете такие команды, как php artisan, ваш компьютер должен записывать файл журнала в хранилище».
Станислав Потапенко

Ошибка на mac: chown: www-data: недопустимое имя группы
Сунил Кумар,


7

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

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

sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache

7

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

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

После composer install


2
Это плохой ответ. Вам никогда не нужно использовать 777 для любой папки, если вы правильно настроили веб-сервер. Использование 777 открывает ваш сервер для любого хакера, чтобы загрузить файл и выполнить указанный файл, если они знают, где находится папка.
Mbozwood

2
Ладно. Что вы предлагаете?
Даврон Ачилов

И если так, будет ли это правильно? chown -R $ USER: хранилище www-данных, chown -R $ USER: загрузчик / кэш www-данных
Даврон Ачилов

Смотрите правильный ответ, он содержит всю необходимую информацию, которую вы абсолютно можете поместить в пост-обновление :)
mbozwood

6

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


4

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

3

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

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. это зависит от разрешений вашего пользователя, группы и т.д ...


2

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

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

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

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

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


2

Я установил 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/

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

  1. и не забудьте об этом обновлении композитора php artisan cache: clear

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

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


Вы пытались вызвать скрипт командной строки с веб-сервера? У меня проблема, так как она не печатает никаких выходных данных
Volatil3

0

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

  • 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

Для разработчиков 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);


-1

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


Если посетителю веб-страницы удастся вырваться из веб-сервера, у него теперь будут права доступа «пользователя, которому принадлежат каталоги». Если этот пользователь имеет www-данные, он может нанести ограниченный ущерб, и поэтому apache работает как пользователь с ограниченными правами. Если этот пользователь не ограничен, он может нанести больше урона. Если этот пользователь имеет права sudo, он может нанести гораздо больший ущерб.
markdwhite

То же самое касается apache. Кстати, я бегу nignx, как большой мальчик сейчас
Сесил Меррел ака принесите огонь
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.