Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96828
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 104.47.38.99 as permitted sender)
To: "php-dev@coydogsoftware.net" <php-dev@coydogsoftware.net>
CC: Dmitry Stogov <dmitry@zend.com>, "rasmus@lerdorf.com"
	<rasmus@lerdorf.com>, "internals@lists.php.net" <internals@lists.php.net>,
	"Anatol Belski (ab@php.net)" <ab@php.net>, Zeev Suraski <zeev@zend.com>
Thread-Topic: [PATCH] opcache bug #69090, prepend user identifier to keys
Thread-Index: AQHSO+21D4h3upkAiEqzeDgxtnu8Qg==
Date: Fri, 11 Nov 2016 07:40:56 +0000
Message-ID: <MWHPR02MB2477BC9B59DC305ADDCAEC65BFBB0@MWHPR02MB2477.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_MWHPR02MB2477BC9B59DC305ADDCAEC65BFBB0MWHPR02MB2477namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2016 07:40:56.0320
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2479
Subject: Re: [PATCH] opcache bug #69090, prepend user identifier to keys
From: dmitry@zend.com (Dmitry Stogov)

--_000_MWHPR02MB2477BC9B59DC305ADDCAEC65BFBB0MWHPR02MB2477namp_
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

On Nov 11, 2016 2:20 AM, php-dev@coydogsoftware.net wrote:
>
> Hello Dmitry,
>
> A quick question after considering your comments and doing a bit more
> homework on extension lifetime:
>
> On Thu, Nov 10, 2016 at 08:10:19AM -0600, php-dev@coydogsoftware.net wrot=
e:
> >
> > On Thu, Nov 10, 2016 at 08:51:58AM +0000, Dmitry Stogov wrote:
> > >
> > > The patch introduces syscall in the hot function (this may be
> > > optimized).
> >
> > Agreed. That isn't ideal. But the geteuid() call shouldn't be done
> > during opcache initialization when the SHM object is initialized,
> > because EUID might change afterwards. I didn't want to get EUID too
> > early so I erred on the side of caution, getting it at the last possibl=
e
> > moment. This is slower but safer because it prevents trivial cross-user
> > cache access from PHP userland. I'm open to suggestion if there's a mor=
e
> > "local" initialization function outside of key generation, which is
> > guaranteed to run after EUID changes in both FPM user pool, and
> > mod_ruid2/mod_php.
>
> Looks like OPCache currently does not implement a request_startup_func fo=
r
> per-request initialization. I'm assuming this was avoided for
> performance reasons and due to no perceived need until now for
> per-request initialization. This seems like it would be the proper point
> in extension lifetime to call geteuid() and save results in the
> zend_accel_globals struct to use during key construction. Correct? Any
> objection to my implementing this?

See zend_accel_activate() in ZendAccelerator.c

>
> I'm also thinking the stat() for device+inode should be done in opcache
> code at file compilation time; correct?

It's not a problem to make extra stat() at script compile (I think we alrea=
dy do it to record mtime), however we will have to do it also on each acces=
s.

>
> Would this be a step in the right direction? Apologies if these are
> basic questions; I'm new to PHP extensions but strongly motivated to fix
> OPCache keys quickly. I may have time for a second pass at this over the
> weekend.

I see your point, but I don't like a quick fix, I like a "good" fix.
And I hope, our discussion could lead us to some better solution :)

Thanks. Dmitry.

>
> -php-dev at coydogsoftware dot net

--_000_MWHPR02MB2477BC9B59DC305ADDCAEC65BFBB0MWHPR02MB2477namp_--