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

From: Date: Thu, 05 Jul 2018 19:04:41 +0000
Subject: Bug #76573 [Opn->Fbk]: Log file is created with wrong permissions if deprecated configuration found
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-216153@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76573&edit=1 ID: 76573 Updated by: ab@php.net Reported by: mbiebl at messageconcept dot com Summary: Log file is created with wrong permissions if deprecated configuration found -Status: Open +Status: Feedback Type: Bug Package: IIS related Operating System: Windows Server 2016 PHP Version: 7.2.7 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2018-07-04 14:15:32] ab@php.net Thanks for the report. Does your INI have fastcgi.impersonate=1? The deprecation warnings are thrown at startup, so any relevant operation at that stage happens under a user configured in IIS. Thanks. ------------------------------------------------------------------------ [2018-07-03 15:49:37] mbiebl at messageconcept dot com Description: ------------ We run PHP 7.2.7 under IIS/Windows Server 2016. php.ini is setup to log to error_log = "C:\Windows\temp\PHP72_errors.log" We also use PHP Manager for IIS. If you use PHP Manager to switch into Development mode, it will add the following to php.ini: track_errors = On With 7.2.7 this will trigger a deprecation warning. A side effect of this is, that if the log file C:\Windows\temp\PHP72_errors.log does not exist, it will be created containing this line [03-Jul-2018 17:37:22 Europe/Berlin] PHP Deprecated: Directive 'track_errors' is deprecated in Unknown on line 0 but more importantly the file permissions will be wrong. The IUSR (which is used by IIS) will have no read/write/access permissions at all. So subsequent calls to error_log() will fail. If I remove "track_errors = On" from php.ini and trigger the file creation via error_log() the file permissions are correct. It seems when the php.ini is parsed and the deprecation notice logged, a different code path is used to create the log file which does not setup proper file permissions. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=76573&edit=1

« previous php.bugs (#216153) next »