Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105606
MIME-Version: 1.0
Date: Tue, 7 May 2019 12:11:03 +0200
Message-ID: <CAF+90c-4-R4SYY_AAL679ZYBn2QAZTYAGXH6E6Bz1hYGN=MFcA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002e4ad905884970ef"
Subject: open_basedir?
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000002e4ad905884970ef
Content-Type: text/plain; charset="UTF-8"

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

--0000000000002e4ad905884970ef--