php exec возвращает 127, потому что /bin/sh получает сообщение «Отказано в доступе» в apache chroot

php exec возвращает 127, потому что /bin/sh получает сообщение «Отказано в доступе» в apache chroot

У меня есть скрипт php, который пытается использовать exec (или shell_exec) для выполнения двоичного файла в системе. Exec завершается с кодом возврата 127.

Код возврата 127 обычно означает, что команда не найдена. Поэтому я убедился, что использовал абсолютный путь к бинарнику. Никаких изменений.

Apache настроен для работы в chroot-окружении с использованием ChrootDir.

Я убедился, что скопировал двоичный файл по правильному пути в chroot, а также /bin/sh и все связанные библиотеки, необходимые для обоих.

Apache (и, следовательно, php) работают как www-data. Я подтвердил, что www-data имеет разрешение на чтение и выполнение бинарных файлов (включая /bin/sh) и всех родительских папок. Чтобы подтвердить, что это не проблема с правами доступа к файлам, я выполнил команду с помощью /bin/sh -c с использованием sudo:

sudo -u www-data /chrootdir/bin/sh -c /chrootdir/path/to/binary

И это работает без проблем.

Используя strace, я получаю это:

execve("/bin/sh", ["sh", "-c", "/path/to/binary"], 0x7ffe436b3618 /* 11 vars */) = -1 EACCES (Permission denied)

Просто чтобы убедиться, что проблема с правами доступа касается двоичного файла sh (и того, который находится в chrootdir), я попробовал переименовать /chrootdir/bin/sh во что-то другое и снова выполнил strace, но теперь он жалуется на то, что файл не найден.

Итак, теперь я знаю, что проблема связана с доступом к /chrootdir/bin/sh при запуске через php через apache, но это не разрешение пользователя www-data.

Я не знаю, что делать дальше.

Работает на Debian 10, Apache 2.4.38 и PHP 7.3.11.

Я очистил open_basedir, а также disable_functions.

Я подтвердил, что Apache не ограничен AppArmor, но все равно отключил его.

Наконец, если я отключу Apache chroot, это сработает.

Итак, у меня вопрос: есть ли еще какие-то ограничения, которые могут помешать Apache сделать это?

решение1

Благодаря комментарию @Michael Hampton выше, я попытался использовать команду chroot, чтобы просто chroot в /chrootdir как root. У меня не получилось. Я бы получил:

chroot: failed to run command ‘/bin/bash’: Permission denied

Я также попробовал, как он предложил, выполнить /bin/sh -c /path/to/binary (но как root, так как www-data не может использовать команду chroot). И это дало ту же ошибку разрешения отказано.

Тот факт, что он нормально выполнялся, когда я просто использовал sudo -u www-data /bin/sh ..., но не с командой chroot, означает, что проблема, должно быть, связана с подключенными библиотеками.

При дальнейшем исследовании библиотека /chrootdir/lib64/ld-linux-x86-64.so.2 не была исполняемой. Сделав ее исполняемой, мы решили проблему.

Связанный контент