Hello, If the plan is to remove it in 8.0, then i'd say its beneficial to already deprecate it in 7.4. This will give users an earlier warning that these upgrades need to happen.
Cheers On Tue, 7 May 2019 at 12:18, Joe Watkins <krak...@gmail.com> wrote: > Morning Nikita, > > It would be wise to do a) and b) regardless of whether it's going to be > removed. > > I think +1 on removing it in 8 ... I'm not sure if it should be deprecated > in 7.4 first, or how that would work ? > > Cheers > Joe > > On Tue, 7 May 2019 at 12:11, 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. > > > > 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. > > > > 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 > least > > > > a) 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. > > > > Regards, > > Nikita > > >
