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

From: Date: Fri, 13 Sep 2019 10:26:03 +0000
Subject: Bug->Doc #76573 [Opn]: Log file is created with wrong permissions if deprecated configuration found
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-16939@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: cmb@php.net Reported by: mbiebl at messageconcept dot com Summary: Log file is created with wrong permissions if deprecated configuration found Status: Open -Type: Bug +Type: Documentation Problem Package: IIS related Operating System: Windows Server 2016 PHP Version: 7.2.7 Block user comment: N Private report: N New Comment: Changing to documentation problem according to Anatol's comment. Previous Comments: ------------------------------------------------------------------------ [2018-07-23 13:38:26] ab@php.net There seems no good way to solve this issue. Perhaps, one could temporarily redirect all the logging to syslog while in the startup phase. I had a partial try on that and it seems like it could work. But that way the information would go into a non obvious location where error_log where configured to be a file. Another idea were to touch the error log file with permissions for IUSRS after the startup was done. Here is the obvious issue, that we can't reliably determine whether the FCGI process indeed runs under IIS. Even if fastcgi.impresonate is set. Another solution that should work better is to use some path outside c:\windows\temp. The permission issue exists, because any file inside c:\windows inherits very strict permissions. Once the log file was created as system, an impersonated process won't be able to access it because the created file inherits the security attributes from c:\windows. Putting the log file into some other location with less strict permissions would solve this. Otherwise I would say it is a documentation issue. I think, c:\windows should not be used for any writing operations anyway. The solution would be either usisg syslog or using a path outside c:\windows with a bit more lose permissions. @mbiebl btw the syslog issues should be fixed now. Not sure they're released yet, but the latest snapshots should be fine in that regard. Thanks. ------------------------------------------------------------------------ [2018-07-05 21:31:26] mbiebl at messageconcept dot com Hi Anatol, I'd say let's focus on the issue at hand in this bug report. If I find time to generate a backtrace I'll file a separate bug report for the php-cgi.exe crash ------------------------------------------------------------------------ [2018-07-05 21:01:19] ab@php.net Or some relevant configs, at least. Thanks. ------------------------------------------------------------------------ [2018-07-05 21:00:14] ab@php.net @mbiebl could you please share a backtrace or a crash dump from the case the syslog scenario crashes? See https://bugs.php.net/bugs-generating-backtrace-win32.php Thanks. ------------------------------------------------------------------------ [2018-07-05 20:18:32] spam2 at rhsoft dot net well, having logfiles in C:\Windows\temp\PHP72_errors.log must be a Windows attitude, i am out here... ------------------------------------------------------------------------ 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

« previous php.doc.bugs (#16939) next »