I have a php script that is trying to use exec (or shell_exec) to execute a binary on the system. The exec is failing with return code 127.
Return code 127 normally means command not found. So I made sure to use the absolute path to the binary. No change.
Apache is configure to run in a chroot using apache's ChrootDir.
I've made sure to copy the binary into the proper path in the chroot, as well as /bin/sh, and all the linked libraries needed for both of those.
Apache (and therefore php) are running as www-data. I've confirmed that www-data has read and execute permission to the binaries (including /bin/sh) and all the parent folders. To confirm that it is not a file permission issue, I've run the command using /bin/sh -c using sudo:
sudo -u www-data /chrootdir/bin/sh -c /chrootdir/path/to/binary And that works without problems.
Using strace, I get this:
execve("/bin/sh", ["sh", "-c", "/path/to/binary"], 0x7ffe436b3618 /* 11 vars */) = -1 EACCES (Permission denied) Just to confirm that the permission issue is for the sh binary (and the one in the chrootdir) I tried renaming /chrootdir/bin/sh to something else and did the strace again and now it complained about file not found.
So, I now know that the problem is with the access to /chrootdir/bin/sh when run via php through apache, but is not a permission of the www-data user.
I'm not sure what to try next.
This is running on Debian 10, apache 2.4.38, and php 7.3.11.
I've cleared open_basedir, and I've also cleared disable_functions.
I've confirmed that apache is unconfined by apparmor, but disabled it anyways.
Finally, if I disable the apache chroot, this does work.
So my question is there any other restriction somewhere that might be stopping apache from doing this?
sudo -u www-data chroot /chrootdir /bin/sh -c /path/to/binary.