PHP не может выполнить какую-либо внешнюю команду?

Мы перешли со Slackware на CentOS, здесь все работало нормально, без предупреждения php прекратил выполнять внешние вызовы, такие как "wc" и "spamc". Все такие вызовы появляются в error_log как:

sh: / usr / bin / spamc: в доступе отказано

Пути верны. У нас правильно установлены разрешения, и Apache должен без проблем выполнять файлы. Мы НЕ на Safe_mode, и у нас нет установленного base_dir. Это не SELinux, или, по крайней мере, sestatus говорит, что SELinux отключен.

резюме:

  • PHP не может выполнить что-либо через exec() или popen()
  • Пути к двоичным файлам верны.
  • Мы не в безопасном режиме
  • У нас нет установленного base_dir
  • Разрешения на двоичные файлы позволяют пользователю Apache выполнять их
  • SELinux отключен
  • на php.ini параметр disable_functions пуст
  • Мы понятия не имеем, почему это не работает

PHP версии 5.3.3 и CentOS 5.5

Кто-нибудь знает, что может происходить? заранее спасибо

Источник

2 ответа

Решение

Нашел ошибку.

Например, я пытался выполнить / usr / bin / tidy, папка usr имела разрешение 644, что сродни любовному ужасу в моей книге. Я мог работать, потому что я был root.

Я понял это после того, как сошел с ума и решил проверить разрешения для всех компонентов пути команды от корня / папки до двоичного файла tidy, я обнаружил, что все разрешения установлены правильно, но перманенты папки usr были полностью испорчены.

Это исправлено.

Источник

Разрешения?

Это хиты разрешений... имейте в виду

"Отказано в доступе" может быть в любом месте пути, а не только в файле, который вы вызываете. Посмотрите также на "/ usr / usr / bin" и "/".

PHP

Это также может быть связано с тем, что php не скомпилировал что-то, что ему нужно. Можете ли вы включить strace и попробовать снова?

чтобы сделать это - вам нужно будет остановить / запустить apache / exim (или что-то еще) с включенным strace:

strace -f -o trace.txt /etc/rc.d/init.d/servicename  start

Вообще это Apache кстати

strace -f -o trace.txt /etc/rc.d/init.d/httpd start Теперь просто попробуйте снова запустить функцию

Поскольку опция "-o" сохраняет результат в файл "trace.txt", давайте продолжим и посмотрим @ этот файл:

cat trace.txt | grep "/usr/bin/spamc"

Это должно позволить вам увидеть намного лучший журнал и намек на то, что происходит

Убедитесь, что вы выключили эту полоску - иначе журналы станут очень большими

Источник
Другие вопросы по тегам