Bug #76573 [Opn->Fbk]: Log file is created with wrong permissions if deprecated configuration found
| From: | ab@php.net | 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