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-...@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? I'm also thinking the stat() for device+inode should be done in opcache code at file compilation time; correct? 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. -php-dev at coydogsoftware dot net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
