| Summary: | journal export allows field injection | ||
|---|---|---|---|
| Product: | systemd | Reporter: | geoffsheep.johnstonefrog |
| Component: | general | Assignee: | Zbigniew Jedrzejewski-Szmek <zbyszek> |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Actually, utf8_is_printable_newline is invoked with false as the last argument, so it does not accept newlines. Running your example gives me: _TRANSPORT=journal ... MESSAGE ^S^@^@^@^@^@^@^@MESSAGE=bar _UID=99 ... The field is exported as binary. I adjusted the specification to allow non-control utf-8 characters, apart from the newline. ah yes, sorry - fixed in commit 0ade5ffe2778e7b238bba8d979ca4d53dee1e702, which isn't in the RHEL7[.0] version (v208). I ran the example on a RHEL7 box; that's therefore a RH bug rather than an upstream problem. Ooops, I even fixed it myself ;) I forgot about that commit completely. This definitely should be backported. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
The specification says that fields are exported as strings iff they're printable ASCII (>= 32, < 127). However, the implementation (on RHEL7 at any rate, and by inspection in the current git master) decides this with "utf8_is_printable_newline", which will use string export if the data are valid UTF-8 codepoints, or tab, or newline. Apart from the inconsistency here, allowing newline lets us do things like this: sd_journal_send("MESSAGE=bar\n_UID=99") which, when exported, gives: ... CODE_LINE=9 MESSAGE=bar _UID=99 _PID=9045 .. i.e. formally ambiguous, grammatically.