[systemd-devel] trust of kernel messages re-routed via journald

Lennart Poettering lennart at poettering.net
Mon Mar 5 05:45:17 PST 2012


On Mon, 05.03.12 14:29, Rainer Gerhards (rgerhards at gmail.com) wrote:

> > Note that on F17 (and most likely for much longer) systemd does not take
> > control of /proc/kmsg and leaves that to syslog-ng/rsyslog.
> 
> Sure, but the question was with a bit broader scope, assuming this
> will change in the future.

Actually it might not change in the future as we have some rough plans
to allow classic syslog to take posession of /proc/kmsg, while systemd
uses a different, new interface in its place.
> >> - syslogd uses SCM_CREDENTIALS on the journald provided socket
> >>
> >> Question now: what pid will I see inside SCM_CREDENTIALS (0, 1, s/t
> >> else)? I assume I can use the pid to tell the difference between a
> >> real message and a faked one from some user process. Is that a correct
> >> assumption?
> >
> > You will see systemd's own PID if we have no other sensible PID to fill
> > in. And if a message originates from the kernel we have no PID.
> 
> OK, so it will be 1, I guess the same like systemd emitted messages.
> Does it sound decent enough to check if the PID is 1 AND the facility
> is kernel THEN this message is actually from the kernel log?
> 
> I am asking because a couple of folks handle messages differently just
> because of their origin. So I think how to emulate this previous
> behavior when running under Journal.

Yes, the facility value is a good idea to use, as we make carefully sure
to always set it to something != 0 (i.e. not kernel) if userspace
generates a message.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list