Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105638
MIME-Version: 1.0
References: <CAF+90c-4-R4SYY_AAL679ZYBn2QAZTYAGXH6E6Bz1hYGN=MFcA@mail.gmail.com>
 <5ac2a666-61e3-877b-6c4d-6b4b78996c91@gmail.com>
In-Reply-To: <5ac2a666-61e3-877b-6c4d-6b4b78996c91@gmail.com>
Date: Wed, 8 May 2019 09:23:24 +0200
Message-ID: <CAF+90c8_MRQ=FvtKtNb89AvHX=oaG4B8D118_Trx+108gvdmCA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007d39f205885b3690"
Subject: Re: [PHP-DEV] open_basedir?
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000007d39f205885b3690
Content-Type: text/plain; charset="UTF-8"

On Tue, May 7, 2019 at 9:05 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > 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.
>
> I think we've been treating them this way effectively for a while now.
>
> The big question is how we formulate what open_basedir actually *is*. I
> mean, some people find it rather useful, and in some situation such
> mechanism can be very valuable - one scenario I can think of it turning
> on open_basedir, run through application test suite and check that it
> doesn't reach anywhere it should not. It, of course, does not provide
> security guarantees, neither do unit tests, but we still find unit tests
> useful, and in the same vein people may find open_basedir useful.
>
> So before just swinging the ax and dropping it I think we should really
> research what people are actually using open_basedir for. And then try
> to formulate a proper description of what it can be used for without
> claiming any security guarantees we could not deliver.
>

Right. One practical question that would interest me in particular is if we
can drop the implicit disabling of the realpath cache if open_basedir is
enabled. It makes open_basedir trivially bypassable, but still requiring
some specially crafted code -- not something that just happens by accident.
If we see open_basedir as a non-security feature for detecting code that
accidentally tries to access things it shouldn't, that should be fine. But
I'm not quite sure if that's the right interpretation.

I don't really care myself whether open_basedir exists or not, I mainly
want users (and ourselves as well) to understand what the intended usage
and limitations are.

Regards,
Nikita

--0000000000007d39f205885b3690--