У меня PHP запущен как DSO. Таким образом, мой скрипт установщика (который пишет в файл конфигурации) не может ничего писать.
Как предоставить Apache (пользователь: nobody) возможность записи в файл?
решение1
Я бы сделал это только на сервере разработки в защищенной среде. Многие приложения PHP генерируют файл на экране, чтобы его можно было безопасно скопировать в каталог конфигурации.
Быстрый (и небезопасный) способ сделать это — выполнить chmod 777 .из каталога, куда должен быть помещен файл. Перед выполнением этого запуска, ls -ld .чтобы получить разрешения, которые вы будете устанавливать обратно. В некоторых случаях требуемый каталог не будет существовать, поэтому вам нужно будет сначала создать его. Сразу после записи файла конфигурации сбросьте каталог до его исходных разрешений. Правильная команда, скорее всего, chmod 755 .или chmod 750 .запустите из каталога. Проверьте с помощью команды ls.
Измените разрешения на файл конфигурации, чтобы Apache больше не мог писать в него ( chmod o-w configfile). Приложения часто поставляются с примерами файлов конфигурации. Размещение одного из них в каталоге конфигурации и редактирование может быть лучшим подходом. Для этого вам необходимо изучить и понять параметры конфигурации. Вы можете использовать скрипт онлайн-конфигурации для упрощения редактирования.
решение2
Вы можете записать свои файлы конфигурации во временный каталог, например /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";
?>
решение3
В общей среде все становится немного сложнее, когда дело касается проблем безопасности. Изменяя владельца файла на «никто», вы даете Apache право записи в этот файл, но если модуль PHP не имеет настроек, ограничивающих каждый виртуальный хост его собственным каталогом, он также предоставит другим доступ к нему. Проверьте, как это настроено в вашей среде.
Apache обычно запускается как пользователь 'nobody' и группа 'nobody', так что вы можете поиграться с групповыми правами доступа. Измените группу файла на 'nobody' и установите права доступа 664.
Если вы не можете изменить владельца или группу файла, FTP обычно позволяет вам изменить разрешения. Предполагая, что Apache не является одним из пользователей/групп, владеющих этим файлом, вам придется установить его на 777, что очень небезопасно, но все зависит от типа среды, в которой вы находитесь. Возможно, вы можете установить его временно, установить свое приложение и изменить его обратно на 644 или 444 (только для чтения).
решение4
Это типичная проблема при запуске PHP как DSO с cPanel, но она применима и к другим настройкам.
При запуске этого метода PHP-процессы обрабатываются пользователем, который запускает httpd. В большинстве случаев этот пользователь — пользователь «nobody». Это означает, что когда PHP взаимодействует с файлами в файловой системе, они должны быть доступны пользователю «nobody». Это создает проблемы с разрешениями, так как ваш обычный пользователь на основе cPanel не будет иметь доступа к файлам RW (чтение/запись), которые принадлежат пользователю «nobody», без правильного изменения разрешений. Большинству веб-приложений/скриптов PHP необходимо записывать в файлы и каталоги, и если они принадлежат пользователю cPanel, без изменения разрешений на файлы/каталоги на 777, это вызовет проблемы и в некоторых случаях нарушит работу вашего веб-сайта(ов).
Поэтому в этом случае вы можете просто вручную управлять разрешениями, установив их на 777.
При запуске этого метода PHP вам придется вручную управлять разрешениями для каждого пользователя, чтобы гарантировать, что ваши приложения/скрипты PHP могут читать и записывать файлы и каталоги, необходимые для их работы.
Или, что еще лучше, если вы можете перейти на Mod_SuPHP и у вас нет проблем с производительностью (так как DSO намного быстрее), вы сможете запустить PHP от имени пользователя, запустившего cPanel.
Если не обращать внимания на проблемы с разрешениями, с которыми можно столкнуться при запуске PHP через DSO, то у него есть некоторые преимущества по сравнению с SuPHP. Первое — скорость. Mod_PHP быстрее Mod_SuPHP. Это в основном связано с тем, что каждый запрос, обрабатываемый Mod_SuPHP, упакован для запуска от имени пользователя, владеющего файлами. Это может быть не очень заметно на сайтах с низким трафиком, но на сайтах с высоким трафиком это может довольно быстро проявиться. Второе — полная функциональность с дополнениями к кэшированию опкодов PHP, такими как eAcclerator, APC и Xcache. Чтобы получить все преимущества кэширования опкодов PHP, вам нужен общий пользователь, который используется при кэшировании скомпилированного байт-кода PHP, а запуск PHP через DSO запускает PHP, поскольку пользователь «nobody» удовлетворяет эту потребность. Вы можете узнать, настроен ли ваш сервер для запуска PHP через DSO, перейдя в WHM и посмотрев в разделе Main >> Service Configuration >> Apache Configuration . >> PHP и SuExec Configuration
Более подробную информацию можно найти здесь:
https://helpdesk.wiredtree.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1663