On Tue, May 7, 2019 at 1:11 PM Nikita Popov <nikita....@gmail.com> wrote:
> Hi internals, > > The open_basedir ini setting has two significant problems: > > 1. It is a major performance hit, because it disables the realpath cache. > That's true, but only if it's in use. That's kind of fair... > 2. 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. > Agreed 100%. > 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). > Ditto > I wonder if it is feasible to drop this ini setting? Enforcing this doesn't > really seem like any of PHP's business. It's definitely feasible, although personally, I think the right way to go here is more around docs and policy. It's not completely without value, and I believe I've seen it being used in a lot of different places (most of them realizing the fact it's a 'best effort' feature and not a bulletproof one). I wouldn't introduce it today, but I don't see the compelling case the remove it. If not, I think we need to at least > > a) make it clear in the documentation that this is *not* a security option > and only exists to prevent "accidents" and > I'm not sure I'd phrase it that way exactly, but generally I very much agree. I think we should say it's just an extra safety net, that is in no way comprehensive and can therefore not be relied upon when security is needed. 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. Agreed 100%. Zeev
