Bug #74860 [Com]: Uncaught exceptions not being formatted properly when error_log set to "syslog"

From: Date: Wed, 05 Jul 2017 23:25:23 +0000
Subject: Bug #74860 [Com]: Uncaught exceptions not being formatted properly when error_log set to "syslog"
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-209835@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74860&edit=1 ID: 74860 Comment by: philipp at redfish-solutions dot com Reported by: philipp at redfish-solutions dot com Summary: Uncaught exceptions not being formatted properly when error_log set to "syslog" Status: Open Type: Bug Package: Output Control Operating System: linux 4.9.30 PHP Version: 7.1.6 Block user comment: N Private report: N New Comment: For what it's worth, I'm using syslog-ng 3.9.1 on my system. In the case of using rsyslog, the message would have been reformatted as it was written to disk with newlines being replaced literally with "\012" (i.e. an escaped octal sequence). Also not desirable. Previous Comments: ------------------------------------------------------------------------ [2017-07-05 23:18:47] philipp at redfish-solutions dot com > this patch tries to address the existing flaw > but: this patch turns a single MSG into multiple messages while keeping invalid characters. The patch is a very specific point-fix: it attempts to handle the known case of embedded newlines being generated by built-in code itself. Newlines are a specific issue and how to handle them in the case of syslog is tacitly understood: if syslog is a line-oriented logging protocol (which it definitely is), then it must be sent multiline messages as multiple single lines. The larger, more abstract problem of how to handle *any* control character is not what is being addressed. > I don't think there is an overall conses [sic] on how to handle this, the RFC suggests > that a receiver has to deal with that if non-printable (non-allowed) characters are used in the MSG > part. That's entirely irrelevant: this bug is how the sender should properly format his messages, not how the receiver should handle malformed messages as you purport. We most certainly do know how to handle things on the sending side: send well-formed messages. There's no equivocation on this point. ------------------------------------------------------------------------ [2017-07-05 22:12:25] hanskrentel at yahoo dot de The MSG can not contain any non-printable characters (below %d32, higher than %d126). currently those invalid MSG characters are not treated in any way, there is no input validation. this patch tries to address the existing flaw. but: this patch turns a single MSG into multiple messages while keeping invalid characters. I don't think there is an overall conses on how to handle this, the RFC suggests that a receiver has to deal with that if non-printable (non-allowed) characters are used in the MSG part. I can imagine similar things when using UTF-8 in the MSGs containing octet sequences leaving the %d32-126 range. ------------------------------------------------------------------------ [2017-07-05 20:43:08] philipp at redfish-solutions dot com Citing RFC 3164: 4.1.3 MSG Part of a syslog Packet The MSG part will fill the remainder of the syslog packet. This will usually contain some additional information of the process that generated the message, and then the text of the message. There is no ending delimiter to this part. The MSG part of the syslog packet MUST contain visible (printing) characters. [...] ------------------------------------------------------------------------ [2017-07-05 20:36:39] philipp at redfish-solutions dot com Description: ------------ I'm using php-7.1.6 on Linux (LEDE master). During development, I had an uncaught exception which generated the diagnostic: 2017-07-05T11:56:20-06:00 PowercodeBMU Powercode: Error: Call to undefined function fetch() in /www/lib/php/LogController.php:48 Stack trace: #0 /tmp/foo.php(7): LogIterator->valid() #1 {main} i.e. 4 lines of text with embedded newlines. syslog() doesn't handle this correctly, as each line is supposed to be prefixed with a timestamp, hostname, and tag... but only the first line is formatted correctly because syslog() is handling the buffer as a single string. The correct behavior is to explode this message on newlines and then write each part to syslog individually. My php.ini file contained: error_log = "syslog"; Test script: --------------- Just about any uncaught exception should trigger this. Expected result: ---------------- Correct logging should look like: 2017-07-05T11:56:20-06:00 PowercodeBMU Powercode: Error: Call to undefined function fetch() in /www/lib/php/LogController.php:48 2017-07-05T11:56:20-06:00 PowercodeBMU Powercode: Stack trace: 2017-07-05T11:56:20-06:00 PowercodeBMU Powercode: #0 /tmp/foo.php(7): LogIterator->valid() 2017-07-05T11:56:20-06:00 PowercodeBMU Powercode: #1 {main} note that each line is prefixed identically. Actual result: -------------- Per description. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74860&edit=1

« previous php.bugs (#209835) next »