On Mon, Jul 8, 2024 at 11:14 PM Dusk <d...@woofle.net> wrote: > On Jul 8, 2024, at 14:12, David CARLIER <devne...@gmail.com> wrote: > > Through this existing PR, I wanted to know how would appeal to you > adding some access restriction upon this existing call, using the open > basedir check. So if the sysadmin wants the php user having no business > calling `/bin` commands for examples would do that, bringing a bit more of > the former suhosin "spirit" here. > > open_basedir is usually used in conjunction with the disable_functions > directive to disable all functions which execute external commands, > including pcntl_exec(). It's largely ineffective if the user can execute > external commands, as those commands are not themselves restricted by > open_basedir. (For instance, if PHP is allowed to execute /bin/cat, that > can be used to read any file; if it can execute /bin/sh, that can execute > any other command.) Additionally, if there *are* PHP installations which > set open_basedir but do allow pcntl_exec(), this change would introduce a > major incompatibility by disallowing all commands. > > If your goal is to restrict what external commands can be executed by a > PHP script, any solution would need to be applied to all functions which > can execute shell commands - exec(), shell_exec(), system(), passthru(), > proc_open(), shell_exec(), popen(), not just pcntl_exec(). Keep in mind > that some of these functions take a string as input which is parsed by the > shell; implementing path-based restrictions may be very difficult to do in > a general fashion.
Completely agree with this. Using open_basedir would be just a hard to catch BC break without any extra protection. So -1 on this proposal. Cheers Jakub
