Команда php shell_exec () не работает
Я пытаюсь запустить файл .sh с php. Я попытался сделать это с shell_exec (). но это не работает Я упоминал много вопросов, связанных с этим в переполнении стека, но не смог решить
мой код php (web.php)
только сделано напечатано. но он работает с терминала (php /var/www/project/web.php)
В xxe.sh я вызываю файл Python
Я также изменил разрешение файла на 777 для обоих файлов .sh n .py пожалуйста, помогите
7 ответов
Если это хорошо работает в оболочке, я думаю, что apache является chroot. Так что php не может найти /var /.
Или пользователь httpd не имеет разрешения на ввод /var /.
Если вы хорошо разбираетесь в PHP. Откройте dir /var /. И readdir () и проверьте, что dir существует, и проверьте, существует ли файл.
Если вы говорите, что он работает на терминале, а не на apache, то файл php.ini apache может отключить использование shell_exec()
Файл php.ini вашего Apache может выглядеть примерно так
Удалите shell_exec из этого списка и перезапустите веб-сервер, хотя это является угрозой безопасности, и я не рекомендую ее.
При попытке запустить скрипт, запущенный github post-receive webhook.
Здесь находится каталог моего проекта (клонированное git repo):
Я создаю скрипт внутри вышеуказанного каталога с именем webhook.php:
Выполните следующую команду внутри /var /www /html
Добавьте путь к вашему сценарию в веб-зацепки github.
Проблема обычно в том, что когда вы исполняете код из php, он запускается как пользователь веб-сервера www-data во многих дистрибутивах Linux. Обычно у этого пользователя нет настроенной среды, и из-за этого нет PATH. Используя полные пути в ваших файлах, вы обычно можете преодолеть это.
Я застрял в этой проблеме на несколько часов.
Я думал о решении. 1. переместите ваш скрипт в файл python «script.py» и поместите этот файл в корень вашего сервера. 2. shell_exec («python script.py»);
В любом случае, это работает для меня.
На моем хосте мне пришлось указать другой путь для запуска моего php-файла из shell_exec (). Это не сработало shell_exec(‘/usr/bin/php backgroundtask.php’); .
Хотя это и было shell_exec(‘/opt/php/php-5.5.0/bin/php backgroundtask.php’); .
У меня была такая же проблема, потому что в PHP произошла обратная косая черта.
PHP избегает обратной косой черты, поэтому команда, которая достигает оболочки
поэтому я дал команду, как это
Вы должны дважды избежать обратной косой черты: один раз для PHP и один раз для оболочки.
Источник
Shell exec php не работает
пробовал по разному
с shell_exec без ts с sudo и без еще кучу в инете находил, толку ноль.
права кругом 777
где то мельком видел что в последних версиях пшп отказались от shell_exec и exec, может не так понял. Короч подскажите кто в курсе.
Пользователь www-data не добавлен в sudoers. Пропишите в /etc/sudoers что ему можно выполнять эту команду. И надеюсь что пакет sudo установлен?
записал в /etc/sudoers
www-data ALL=(root) NOPASSWD: ALL
Stopping MySQL database server: mysqld failed! /etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full! . failed! Все хорошо.
$result = shell_exec (‘sudo sh /var/www/1/2.sh’); и $result = shell_exec (‘/var/www/1/2.sh’);
если в 2.sh прописать
echo «TEST» >> out.txt
создается файл в корне сайта.
надо выполнить sudo /etc/init.d/mysql restart в 2.sh
А вручную запускается, может быть действительно нет свободного места?
NOPASSWD: ALL как-то слишком круто. Достаточно было ограничиться одной конкретной командой.
используйте банальный exec и sudo
где USERNAME — имя пользователя, от которого идет запуск
SCRIPT — команда со всеми параметрами
еще можно дать привелегию для service, и сделать что-то вроде:
www-data — юзер от которого запускается скрипт
HOSTNAME надо заменить на хостнейм машины
/usr/sbin/service — полный путь до бинарника
либо то, что находится после -S заменить на путь до скрипта sh, в котором просто прописать service mysql restart
но короткий вариант по идее должен работать (не проверял, но через sh 100% будет работать + в sh ненадо прописывать sudo).
p.s. права 777 незачем ставить
p.s.s. отключите лучше safe mode
Ничего не получилось, решил вопрос запуском пшп из папки под рутом в кроне
пшп скрипт, чекает сайт на доступность, отправляя на мыло, записывая в лог и перезагружая службы (достали уже парсеры, досеры, чекеры, брут вп, и т.д., ложат впс пока проснусь пол дня лежит)
может кому пригодится
Маленький вопрос, как в баш запустить команды по очереди а то работает только последняя
Источник
Отладка проблем с функцией exec
Команда exec не работает на моем сервере, она ничего не делает, у меня отключен safe_mode, и я убедился, что все консольные команды работают, я пробовал использовать абсолютные пути. Я проверил разрешения для приложений, и все приложения, которые мне нужны, имеют разрешения на выполнение. Я не знаю, что еще делать, вот краткое изложение кодов, которые я пробовал :
Вот вывод последних двух кодов:
Я связался со службой сервера, и они не могут мне помочь, они не знают, почему команда exec не работает.
Ответ 1
П осмотрите файл /etc/php.ini :
; Эта директива позволяет отключить определенные функции в целях безопасности.
; Она получает список имен функций, разделенных запятыми. Эта директива
; *НЕ* зависит от того, включен или выключен безопасный режим.
У бедитесь, что exec не определен следующим образом:
Если это так, то просто удалите эту строку и перезапустите apache.
Для облегчения отладки я обычно запускаю файл php вручную (можно запросить вывод на большее число ошибок, не определяя их в основном ini). Для этого добавьте заголовок:
в начало файла, дайте им права доступа chmod +x myscript.php и выполните ./myscript.php . Надо быть осторожным при выполнении данных операций, особенно на загруженном сервере, который много пишет в файл журнала.
И еще дополнительно : это похоже на проблемы с разрешениями . Создайте сценарий bash, который делает что-нибудь простое, echo «hel l o world» , и попробуйте его запустить. Убедитесь, что у вас есть разрешения для файла и для папки, содержащей файл .
Ответ 2
Поскольку вы выходите из контекста PHP в собственную оболочку, у вас будет много проблем с отладкой.
Лучшее и самое надежное, что я использовал, — это запись вывода скрипта в файл журнала и его отслеживание во время выполнения PHP.
Затем в отдельной оболочке:
Когда вы выполняете свой PHP-скрипт, ваши ошибки и выходные данные вашего вызова оболочки будут отображаться в вашем файле debug.log .
Ответ 3
Вот несколько вариантов решения вашей проблемы:
Для отладки всегда оборачивайте вашу функцию exec/shell_exec в var_dump() .
error_reporting(-1); должен быть включен, как и display_errors , в крайнем случае даже set_error_handler(«var_dump»); — хотя бы для того, чтобы проверить, не вызвал ли сам PHP execvp или что-то еще.
Используйте 2>&1 (объедините оболочки STDERR с потоком STDOUT), чтобы узнать, почему вызов не удался.
В некоторых случаях вам может потребоваться заключить вашу команду в дополнительный вызов оболочки:
// захват потока STDERR через стандартную оболочку
echo shell_exec(«/bin/sh -c ‘ffmpeg -opts 2>&1’ «);
Чередуйте различные функции exec для выявления сообщений об ошибках. Хотя в основном они делают одно и то же, пути возврата выходных данных различаются:
- exec()— либо возвращает результат как результат функции, либо через необязательный параметр $output.
Также предоставляет параметр $return_var, который содержит код ошибки/код выхода из запущенного приложения или оболочки. Вы можете получить:
- ENOENT (2) — Нет такого файла
- EIO (127) — Ошибка ввода-вывода: файл не найден
// выполнение команды, сопряженный с stderr, output + код ошибки
shell_exec() — это то, что вы хотите запускать в основном для выражений в стиле shell.
Обязательно назнач ь те/распечатайте возвращаемое значение, например , так : var_dump(shell_exec(«. «));
` встроенные обратные кавычки → идентичны shell_exec .
system() — аналогичен exec , но всегда возвращает результат как результат функции. Дополнительно позволяет фиксировать код результата.
passthru() — еще одна альтернатива exec , но всегда отправляет любые результаты в STDOUT (выходной буфер PHP). Это часто делает его наиболее подходящей альтернативой exec.
popen() или лучше proc_open() — разрешает отдельно захватывать STDOUT и STDERR.
Большинство ошибок оболочки попадают в журнал ошибок PHP или Apache, если их не перенаправить. Проверьте свой системный журнал или журнал Apache, если ничего не дает полезных сообщений об ошибках.
Наиболее распространенные проблемы:
Для устаревших тарифных планов веб-хостинга все еще может быть включен safe_mode или disable_functions. Ни одна из функций PHP exec не будет работать ( л учше всего найти лучшего провайдера, иначе изучите «CGI» — но не устанавливайте свой собственный интерпретатор PHP, пока не разб е ретесь).
Точно так же иногда могут быть установлены AppArmor/SELinux/Firejail. Они ограничивают способность каждого приложения порождать новые процессы.
Предполагаемый двоичный файл не существует. Практически ни у одного веб-хоста нет предустановленных инструментов вроде ffmpeg. Вы не можете просто запускать произвольные команды shell без подготовки. Некоторые вещи должны быть установлены!
PATH отключен. Если вы установили пользовательские инструменты, вам нужно убедиться, что они доступны. Использование var_dump(shell_exec(«ffmpeg -opts»)) выполнит поиск по всем общим путям , или как было сказано/ограничено Apache (часто только /bin:/usr/bin).
Проверьте с помощью print_r($_SERVER);, что содержит ваш PATH и покрывает ли он инструмент, который вы хотели запустить. В противном случае вам может понадобиться изменить настройки сервера (/etc/apache2/envvars) или использовать полные пути:
// запуск с абсолютными путями к двоичным файлам
var_dump(shell_exec(«/bin/sh -c ‘/usr/local/bin/ffmpeg -opts 2>&1′»));
Это в некоторой степени подрывает концепцию shell. Лично я не считаю это предпочтительным. Однако это имеет смысл в целях безопасности; более того, конечно, при использовании пользовательских установок.
Дополнительно:
Для того чтобы запустить двоичный файл в системе BSD/Linux, его необходимо сделать «исполняемым». Именно это делает chmod a+x ffmpeg.
Кроме того, путь к таким пользовательским двоичным файлам должен быть доступен для чтения пользователю Apache, под которым работают ваши PHP-скрипты.
Более современные установки используют встроенный в PHP режим FPM (suexec+FastCGI), где учетная запись вашего хостинга равна той, под которой работает PHP.
Протестируйте с помощью SSH. Это само собой разумеется, но прежде чем выполнять команды через PHP, было бы разумно протестировать его в реальной оболочке. Проверьте, например, ldd ffmpeg, есть ли все lib-зависимости и работает ли он в противном случае.
Используйте namei -m /Usr/local/bin/ffmpeg для проверки всего пути, если не уверены, что могут возникнуть проблемы с разрешением доступа.
Входные значения (GET, POST, имена ФАЙЛОВ, данные пользователя), передаваемые в качестве аргументов команд в строках exec, должны быть экранированы с помощью escapeshellarg().
Следите за тем, чтобы не комбинировать обратные символы с любой из функций *exec():
$null = shell_exec(`wc file.txt`);
Обратные символы выполнят команду и оставят shell_exec с выводом уже выполненной команды. Используйте обычные кавычки для обертывания параметра команды.
Также проверьте в сеансе shell, как предполагаемая программа работает с другой учетной записью:
sudo -u www-data gpg –k
В частности для PHP-FPM проверяйте с соответствующим идентификатором пользователя. www-data/apache в основном используются только в старых настройках mod_php.
Многие инструменты cmdline зависят от некоторой конфигурации для каждого пользователя. Этот тест часто показывает, чего не хватает.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Источник
