Bug 887358 - Logged "[PID]" portion of logger tag is mangled
Summary: Logged "[PID]" portion of logger tag is mangled
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-14 19:27 UTC by John Florian
Modified: 2012-12-22 09:34 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-12-22 09:34:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Script to demonstrate the problem (454 bytes, text/plain)
2012-12-14 19:27 UTC, John Florian
no flags Details

Description John Florian 2012-12-14 19:27:49 UTC
Created attachment 663728 [details]
Script to demonstrate the problem

Description of problem:
It appears that with the introduction of systemd and the Journal for logging, something (systemd?) is altering the tag passed by the logger utility.  Behavior is clearly different starting with Fedora 17.

Version-Release number of selected component (if applicable):
systemd-195-10.fc18.i686

How reproducible:
always

Steps to Reproduce:
1. Download attached test script.
2. Set up a "journalctl -f" (F17 or newer) or "tail -F /var/log/messages" (F16 or older) in one terminal to watch the system log.
3. Run the test script.
  
Actual results:
With F16 and earlier the "[PID]" portion of the system log has a consistent value, specifically that of the bash process running the script -- as desired/needed.  With F17 and later, the PID logged is not that of the bash process.

Expected results:
The script "as is", should give a consistent PID for each of three messages injected into the syslog.  I don't think systemd's journal should be munging the value within the message's tag in any way whatsoever.

Additional info:
Perhaps this is a problem with logger itself.  I've done nothing to prove that one way or another; it just seems suspicious given the "coincidental timing" of this bug and the introduction of the journal.

Note the 3rd form of message injection in the script's syslog() function where the constant "[123]" is part of the tag and how even something that trivial gets mangled.

Comment 1 Lennart Poettering 2012-12-22 09:34:16 UTC
For security reasons we will override the PID with actual client PID, so that arbitrary clients cannot fake arbitrary other PIDs. This makes use of the kernels SCM_CREDENTIALS feature.


Note You need to log in before you can comment on or make changes to this bug.