Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105636
MIME-Version: 1.0
References: <CAF+90c-4-R4SYY_AAL679ZYBn2QAZTYAGXH6E6Bz1hYGN=MFcA@mail.gmail.com>
In-Reply-To: <CAF+90c-4-R4SYY_AAL679ZYBn2QAZTYAGXH6E6Bz1hYGN=MFcA@mail.gmail.com>
Date: Wed, 8 May 2019 06:49:05 +0200
Message-ID: <CANUQDCiGGwjmND34TuS8Z_gZtFKMVh5OF5OaU0e9mLit80eqRg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] open_basedir?
From: me@kelunik.com (Niklas Keller)

Am Di., 7. Mai 2019 um 12:11 Uhr schrieb Nikita Popov <nikita.ppv@gmail.com>:
>
> 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

Hi Nikita,

I'm probably in favor of removing it. If it is used for unit tests to
check file access outside some directory, we could maybe allow it to
be set by code only but not by php.ini?

If we decide to remove it in PHP 8, we should probably trigger a fatal
startup error in case it is configured in php.ini to prevent loosing
the protection entirely for people relying on it.

Regards,
Niklas