Bug #76573 [Opn]: Log file is created with wrong permissions if deprecated configuration found

Edit report at https://bugs.php.net/bug.php?id=76573&edit=1 ID: 76573 User updated by: mbiebl at messageconcept dot com Reported by: mbiebl at messageconcept dot com Summary: Log file is created with wrong permissions if deprecated configuration found Status: Open Type: Bug Package: IIS related Operating System: Windows Server 2016 PHP Version: 7.2.7 Block user comment: N Private report: N New Comment: Well, even if I pre-create the log file somehow (say in the application installer), it's not unthinkable that the admin cleans up C:\Windows\Temp at some point (along with the log file). So I'd need a separate daemon which is running all the time and watches C:\Windows\Temp and immediately re-creates the file. Otherwise, on the next connection attempt the file will be created by php with the wrong permissions again leading to a very hard to debug problem for the admin. Previous Comments: ------------------------------------------------------------------------ [2018-07-05 19:55:13] spam2 at rhsoft dot net where would you store and delay them? logs are written when they happen just make sure that your defined logfiles exist from the begin and have the correct permissions and you are done ------------------------------------------------------------------------ [2018-07-05 19:53:09] mbiebl at messageconcept dot com Just tried to use syslog but then got only 500 errors (php-cgi.exe crashing). ------------------------------------------------------------------------ [2018-07-05 19:26:32] mbiebl at messageconcept dot com Would it be possible to delay the logging of those deprecation warnings until the PHP process runs with the correct privileges? ------------------------------------------------------------------------ [2018-07-05 19:04:37] ab@php.net Thanks for checking. Yes, the impersonation is the only relevant point here. A debug session has confirmed the first assumption I've mentioned. The flow is as follows - IIS itself runs under system or perhaps network service - the PHP process launched by IIS has same privileges - once the PHP process encounters a request, it will impersonate by calling ImpersonateNamedPipeClient() - when the PHP process finishes a request, it'll revert the impersonation by calling RevertToSelf)( That looks like a general collision. As long as the process didn't impersonate, the security will be different. Like in this case - the first warning creates a non existent log file with the privileges insufficient for the impersonated access. A solution to this can be tricky if possible at all. So far some possible workarounds - switch to the syslog facility - if feasible, pre create the log file with acceptable permissions - use a predefined unprivileged account for PHP, might work but not sure Turning off the impersonation is not a solution at all, security-wise! At least you can check to confirm my hypoteses. I'm still looking through the APIs for a solution. If you have some ideas, please share. If there is a way to impersonate the process before it actually accepts a connection, a solution were thinkable. However, it might have impacts in other areas. Thanks. ------------------------------------------------------------------------ [2018-07-05 15:25:40] mbiebl at messageconcept dot com Hi, thanks for your reply. We have the following cgi related settings ini php.ini: cgi.fix_pathinfo=1 cgi.force_redirect=0 fastcgi.impersonate=1 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76573 -- Edit this bug report at https://bugs.php.net/bug.php?id=76573&edit=1