Делать Apache способным писать в файлы PHP с PHP, работающим как DSO?
У меня PHP работает как DSO. Таким образом, мой установочный скрипт (который записывает в файл конфигурации) не может писать.
Как я могу дать apache (пользователь: никто) возможность записи в файл?
4 ответа
Я сделал бы это только на сервере разработки в защищенной среде. Многие приложения PHP генерируют файл на экране, чтобы его можно было безопасно скопировать в каталог конфигурации.
Быстрый (и небезопасный) способ сделать это - выполнить chmod 777 . из каталога, куда должен идти файл. Перед этим ls -ld . чтобы получить разрешения, вы будете устанавливать их обратно. В некоторых случаях требуемый каталог не будет существовать, поэтому сначала вам нужно его создать. Сразу после того, как файл конфигурации был записан, сбросьте каталог к его первоначальным разрешениям. Правильная команда скорее всего chmod 755 . или же chmod 750 . запустить из каталога. Проверьте с помощью команды ls.
Измените права доступа к файлу конфигурации, чтобы Apache больше не мог писать в него (chmod o-w configfile). Приложения часто поставляются с примерами конфигурационных файлов. Размещение одного из них в каталоге конфигурации и редактирование может быть лучшим подходом. Для этого необходимо изучить и понять параметры конфигурации. Возможно, вы сможете использовать онлайн-скрипт конфигурации, чтобы помочь вам с изменениями.
Вы можете записать свои файлы конфигурации во временный каталог, такой как /tmp/config/, Затем вы можете выполнить сценарий оболочки для копирования файлов конфигурации из /tmp/config/ в нужное место.
Чтобы предоставить необходимые разрешения, вы можете добавить пользователя nobody в файл sudoers. Запись должна выглядеть так:
nobody ALL=NOPASSWD: /path/to/your_script.sh
Скрипт оболочки (не забудьте добавить разрешение на выполнение).
cp -r /tmp/config/* /desired/path/to/config
В PHP вам нужен небольшой фрагмент кода, например:
<?php
$output = shell_exec('sudo /path/to/your_script.sh');
echo "$output";
?>
В общей среде все становится немного сложнее, когда речь идет о проблемах безопасности. Изменив владельца файла на "никто", вы дадите Apache доступ для записи в этот файл, но если у модуля PHP нет настроек, ограничивающих каждый виртуальный хост для каждого отдельного каталога, он также предоставит другим доступ к нему. Проверьте, как это настроено в вашей среде.
Apache обычно запускается от имени "никто" и группирует "никто", поэтому вы также можете играть с правами группы. Измените группу файла на nobody и установите разрешение 664.
Если вы не можете изменить владельца файла или группу, FTP обычно позволяет вам изменять права доступа. Предполагая, что Apache не входит в число пользователей / групп, владеющих этим файлом, вам нужно установить для него значение 777, что очень небезопасно, но все зависит от среды, в которой вы находитесь. Возможно, вы можете установить его временно, установите приложение и измените его обратно на 644 или 444 (только для чтения).
Это типичная проблема при запуске PHP в качестве DSO с cPanel, но это относится и к другим настройкам.
При запуске этого метода процессы PHP обрабатываются пользователем, который запускает httpd. В большинстве случаев этот пользователь - "никто". Это означает, что когда PHP взаимодействует с файлами в файловой системе, они должны быть доступны пользователю "nobody". Это создает проблемы с разрешениями, поскольку ваш обычный пользователь на основе cPanel не будет иметь доступа к файлам RW (чтение / запись), которые принадлежат никому, без правильных изменений разрешений. Большинству веб-приложений / скриптов PHP необходимо писать в файлы и каталоги, и если они принадлежат пользователю cPanel, без изменения прав доступа к файлам / каталогам на 777, это вызовет проблемы, а в некоторых случаях нарушит работу вашего веб-сайта (ов),
Таким образом, в этом случае вы можете просто и только управлять разрешениями вручную, установив их на 777
При запуске этого метода PHP вам придется вручную управлять разрешениями для каждого пользователя, чтобы гарантировать, что ваши PHP-приложения / скрипты могут читать и записывать файлы и каталоги, для которых он должен функционировать.
Или, что лучше, если вы можете перейти к Mod_SuPHP и у вас нет проблем с производительностью (так как DSO намного быстрее), вы сможете запускать PHP как пользователь, запускающий cPanel.
Если мы упускаем из виду проблемы с разрешениями, с которыми можно столкнуться при запуске PHP через DSO, у него есть некоторые преимущества по сравнению с SuPHP. Первое - это скорость. Mod_PHP работает быстрее, чем Mod_SuPHP. Это происходит главным образом из-за того, что каждый запрос, обрабатываемый Mod_SuPHP, упакован для запуска от имени пользователя, которому принадлежат файлы. Это может быть не очень заметно на сайтах с низким трафиком, но на сайтах с большим трафиком это может сложиться довольно быстро. Второе - это полная функциональность с добавлением кэширования optcode PHP, таким как eAcclerator, APC и Xcache. Чтобы воспользоваться всеми преимуществами кэша опткода PHP, вам нужен общий пользователь, который используется при кэшировании скомпилированного байтового кода PHP, а запуск PHP через DSO запускает PHP, так как пользователь "nobody" удовлетворяет эту потребность. Вы можете узнать, настроен ли ваш сервер для запуска PHP через DSO, перейдя в WHM и выбрав Main >> Service Configuration >> Apache Configuration . >> Конфигурация PHP и SuExec
Здесь вы можете найти более подробную информацию:
https://helpdesk.wiredtree.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1663