The open_basedir ini setting has two significant problems:
It is a major performance hit, because it disables the realpath cache.
Many people think it is a security feature and use it as such. However,
open_basedir is in reality a "best effort" mechanism, with known
workarounds and more regularly being found. Especially when it comes to
interactions with 3rd party libraries, enforcing open_basedir is simply
impossible.What open_basedir tries to do must be implemented on the operating system
level to work reliably (and of course such mechanisms exist, such as jails,
chroot and friends).I wonder if it is feasible to drop this ini setting? Enforcing this doesn't
really seem like any of PHP's business. If not, I think we need to at leasta) make it clear in the documentation that this is not a security option
and only exists to prevent "accidents" and
b) update the security policy (https://wiki.php.net/security) to state that
open_basedir bypasses are not security issues. I believe this has been part
of Debian's security policy for some time already.
Apparently, there has been no resolution for this issue so far. While I
don't really care about the open_basdedir directive per se, I fully
agree that we should not advertize it as security feature, and to
clearly state this in the PHP manual, as well as in our security policy.
Christoph
Hi!
Apparently, there has been no resolution for this issue so far. While I
don't really care about the open_basdedir directive per se, I fully
agree that we should not advertize it as security feature, and to
clearly state this in the PHP manual, as well as in our security policy.
Correct. As I mentioned, de-facto it's already the case for years now.
Let's fix the docs at least? Though I'd really start thinking about
maybe removing it in the next major version...
Stas Malyshev
smalyshev@gmail.com
On Thu, Jul 8, 2021 at 11:34 PM Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
Apparently, there has been no resolution for this issue so far. While I
don't really care about the open_basdedir directive per se, I fully
agree that we should not advertize it as security feature, and to
clearly state this in the PHP manual, as well as in our security policy.Correct. As I mentioned, de-facto it's already the case for years now.
Let's fix the docs at least? Though I'd really start thinking about
maybe removing it in the next major version...Stas Malyshev
smalyshev@gmail.com
Yeah, feel free to go ahead with updates for docs & security policy.
Regards,
Nikita
On Thu, Jul 8, 2021 at 11:34 PM Stanislav Malyshev smalyshev@gmail.com
wrote:Apparently, there has been no resolution for this issue so far. While I
don't really care about the open_basdedir directive per se, I fully
agree that we should not advertize it as security feature, and to
clearly state this in the PHP manual, as well as in our security policy.Correct. As I mentioned, de-facto it's already the case for years now.
Let's fix the docs at least? Though I'd really start thinking about
maybe removing it in the next major version...Yeah, feel free to go ahead with updates for docs & security policy.
Done with
https://github.com/php/doc-en/commit/c0fb8cac832c2f51f1eb5e5ab7247e8db6a32c2e
and https://wiki.php.net/security?rev=1626103722&do=diff.
Christoph