права на файл для нескольких сайтов [закрыто]
Я потратил более часа на поиск ответов в Интернете, но, что удивительно, ни один из них не подошел к моей проблеме.
У меня есть небольшой выделенный сервер, на котором я размещаю несколько вещей. В основном: сервер Owncloud и несколько сайтов для меня и моих друзей (в основном такие вещи, как Wordpress, MediaWiki...).
Я использую Nginx с разными сайтами (один файл conf.d для каждого сайта).
Для каждого сайта, которому нужен php, я создаю пул php-fpm.
Для каждого сайта :
- Я создаю пользователя: [website_user].
- Я создаю каталог public_html в его доме.
- Если необходимо, я предоставляю пользователю доступ к этой директории через sftp.
- Я настраиваю пул php-fpm на запуск под именем [website_user].
- Я устанавливаю, что все файлы сайта принадлежат пользователю [website_user]:[nginx]
- Я устанавливаю права на файлы каждого сайта на 750
Хорошая ли это практика? Есть ли какие-то недостатки в этой схеме?
На моем Owncloud хранится довольно секретная информация (хотя она зашифрована и это "просто" частный сервер: я не ЦРУ или крупная компания).
Должен ли я запустить другой сервер Nginx в chroot для Owncloud или моя установка достаточно безопасна?
У вас все правильно (пулы PHP-FPM работают под разными пользователями), за некоторыми исключениями.
Допустим, ваши рабочие процессы NGINX работают как nginx и PHP -FPM pool работает как foo .
Начиная с верхней части вашего списка и ниже, проблемы следующие:
Я установил, что файлы каждого сайта принадлежат [website_user]: [nginx] user
Неправильно. Если сценарий PHP создает некоторые файлы (например, обрабатывает загрузку), то этот файл может принадлежать foo: foo . Следовательно, нет никакой гарантии, что NGINX сможет прочитать его позже.
Таким образом, лучший подход состоит в том, чтобы все файлы с самого начала принадлежали foo: foo .
Теперь волшебная вещь - это сделать пользователя, который запускает рабочие процессы NGINX , членом группы пользователей foo . Сложный? Не так:
usermod -a -G foo nginx
Это приведет к тому, что пользователь nginx войдет в группу пользователей веб-сайта foo (дополнительная). Другими словами, пользователь nginx теперь является частью этих групп: nginx и foo . Пользователь сайта foo является членом только foo .
Для еще одного веб-сайта, который будет работать под пользователем bar в другом пуле PHP-FPM, вы сделаем то же самое: добавим пользователя nginx в группу пользователей bar .
Таким образом, теперь вы можете очень гибко определять, что NGINX может видеть, а что нет, путем настройки групповая часть настроек chmod .
Если вы хотите сейчас, вы можете иметь наименее ограничительный chmod, и это будет 0750 для директорий и 0640 для файлов . Тогда NGINX может видеть все, и PHP-FPM тоже. Простой способ установить это для файлов сайта:
chmod -R u=rwX,g=rX,o= /path/to/site/dir
Я использую X , чтобы бит исполняемого файла (то есть обход в контексте dirs) устанавливался только в каталогах. Таким образом, вы получите желаемый 0750 только для каталогов, в то время как файлы имеют вид 0640 .
Но вы можете легко пойти более ограничительно. Скажем, NGINX не должен читать /config.php , потому что он читается исключительно пользователем PHP и не требует «чтения» NGINX, поэтому вы можете легко сделать:
chmod 0600 config.php
И он все равно будет работать как
Если вы не выполняете никаких проверок существования файлов в конфигурации NGINX (например, нет if (-f $ request_filename) {), то вы даже можете установить то же самое 0600 для каждого файла PHP или даже 0400 для конфигурации блокировки :) Например см. мой пост в Конфигурация блокировки Magento .
Я беру на себя смелость добавить кое-что, что считаю очень интересным и что, как ни странно, мало освещалось в Интернете.
В течение нескольких лет рекомендуется отключать OPcache, когда делаю общий хостинг с использованием пулов. Хорошо известная проблема безопасности заключалась в том, что OPcache позволял PHP-процессу пула получать доступ к файлам другого пула, даже если у пользователя не было прав на эти файлы.
Оказывается, эта ошибка была исправлена, но:
- На самом деле он не был опубликован
- Он не включен по умолчанию.
Итак, если ваша версия PHP актуальна (PHP7 <7.0.14 и PHP5 <5.6.29), вы МОЖЕТЕ безопасно включить OPcache в среду пула общего хостинга, если вы добавляете эти параметры в свои настройки:
opcache.validate_permission=1
opcache.validate_root=1
opcache.use_cwd=1