Re: [PATCH] opcache bug #69090, prepend user identifier to keys

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 wrote: > > > > 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 possible > > 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 more > > "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 for > 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 already do it to record mtime), however we will have to do it also on each access. > > 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