Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105635
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 7 May 2019 22:55:06 +0200
References: <CAF+90c-4-R4SYY_AAL679ZYBn2QAZTYAGXH6E6Bz1hYGN=MFcA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <CAF+90c-4-R4SYY_AAL679ZYBn2QAZTYAGXH6E6Bz1hYGN=MFcA@mail.gmail.com>
Message-ID: <5D076029-231F-4380-9FAF-7DA7A33197EB@gmail.com>
Subject: Re: [PHP-DEV] open_basedir?
From: jocelyn.fournier@gmail.com (jocelyn fournier)

Hi!

> Le 7 mai 2019 =C3=A0 12:11, Nikita Popov <nikita.ppv@gmail.com> a =
=C3=A9crit :
>=20
> Hi internals,
>=20
> The open_basedir ini setting has two significant problems:
>=20
> 1. It is a major performance hit, because it disables the realpath =
cache.
>=20
> 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.
>=20
> 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).
>=20
> 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
>=20
> 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.
>=20
> Regards,
> Nikita

The main issue with this option is that it=E2=80=99s used by default by =
hosting control panel like ispconfig / cpanel.
And because of that a lot of users:

1) Are using it without really knowing it
2) Could experienced a major performance impact because of that, but =
don=E2=80=99t really understand why

So deprecating it will at least lead to disabling by default the option =
in those software, which is good :)

--
Jocelyn Fournier
Founder
M : +33 6 51 21 54 10
https://www.softizy.com
Softizy - At your side to Optimize your PHP / MySQL applications