# open_basedir? - Thread: https://externals.io/message/115411 - Original archive: https://news-web.php.net/php.internals/115411 - Started by Christoph M. Becker on 2021-07-12T15:31:30+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #115368 — Christoph M. Becker — 2021-07-08T11:07:23+00:00 URL: https://externals.io/message/115411#115368 > 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. 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 --- ## #115372 — Stanislav Malyshev — 2021-07-08T21:33:53+00:00 URL: https://externals.io/message/115411#115372 · In reply to: #115368 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 --- ## #115406 — Nikita Popov — 2021-07-12T13:54:25+00:00 URL: https://externals.io/message/115411#115406 · In reply to: #115372 On Thu, Jul 8, 2021 at 11:34 PM Stanislav Malyshev wrote: > Hi! > > > […] > > 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 --- ## #115411 — Christoph M. Becker — 2021-07-12T15:31:30+00:00 URL: https://externals.io/message/115411#115411 · In reply to: #115406 > On Thu, Jul 8, 2021 at 11:34 PM Stanislav Malyshev > wrote: > > > […] > > Yeah, feel free to go ahead with updates for docs & security policy. Done with and . Christoph