[systemd-devel] [RFC PATCH] journal: allow callers to specify OBJECT_PID=

[Lennart Poettering]

On Wed, 12.06.13 00:42, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> When journald encounters a message with OBJECT_PID= set
> coming from a priviledged process (UID==0), additional fields
> will be added to the message:
> 
> OBJECT_UID=,
> OBJECT_GID=,
> OBJECT_COMM=,
> OBJECT_EXE=,
> OBJECT_CMDLINE=,
> OBJECT_AUDIT_SESSION=,
> OBJECT_AUDIT_LOGINUID=,
> OBJECT_SYSTEMD_CGROUP=,
> OBJECT_SYSTEMD_SESSION=,
> OBJECT_SYSTEMD_OWNER_UID=,
> OBJECT_SYSTEMD_UNIT= or OBJECT_SYSTEMD_USER_UNIT=.

Hmm, so, do we really want to call this "OBJECT_"? There were ideas to
call it "AUGMENT_" or so... But hmm, maybe "OBJECT_" is better as for
the final viewer it is irrelevant whether journald augmented this or
didn't. Kay, any opinion how this should be called? Otherwise it's
probably good to stick to OBJECT_...

> Actually the restriction that the sender is priviledged is not very
> important, since we are just adding "normal" fields, that the process
> could add itself. I'm keeping it because of the potential information
> leak, where a process has access to the journal but is restricted
> from /proc.

Hmm, also, should this be _OBJECT_EXE= rather than OBJECT_EXE=
(i.e. trusted vs. untrusted)? after all, if journald writes them these
fields are not fakeable...

Hmm, but then again it probably is a good idea that fields we add in
that depend on untrusted fields should be considered untrusted. So I
guess OBJECT_EXE= is right, and better than _OBJECT_EXE=...

> The reader side is more important. We need to figure out how
> to show this information in journalctl and systemctl status, and
> how to figure out if OBJECT_* fields can be trusted. But let's
> decide that after we have the answer to the first two questions.

Filtering for OBJECT_SYSTEMD_UNIT=foobar.service UID=0 should work for
this, too, no?

Looks great otherwise. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.