Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115368
To: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAF+90c-4-R4SYY_AAL679ZYBn2QAZTYAGXH6E6Bz1hYGN=MFcA@mail.gmail.com>
Message-ID: <5af05f50-cf90-c0f2-adb7-b70b57ca1186@gmx.de>
Date: Thu, 8 Jul 2021 13:07:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-4-R4SYY_AAL679ZYBn2QAZTYAGXH6E6Bz1hYGN=MFcA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: open_basedir?
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 07.05.2019 at 12:11, Nikita Popov wrote:

> 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. Howeve=
r,
> 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 syste=
m
> level to work reliably (and of course such mechanisms exist, such as jai=
ls,
> chroot and friends).
>
> I wonder if it is feasible to drop this ini setting? Enforcing this does=
n't
> really seem like any of PHP's business. If not, I think we need to at le=
ast
>
> a) make it clear in the documentation that this is *not* a security opti=
on
> and only exists to prevent "accidents" and
> b) update the security policy (https://wiki.php.net/security) to state t=
hat
> open_basedir bypasses are not security issues. I believe this has been p=
art
> 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