On Fri, Jan 11, 2013 at 09:03:52PM +0100, Lennart Poettering wrote: > On Wed, 09.01.13 22:52, Zbigniew Jędrzejewski-Szmek ([email protected]) wrote: > > > > > We'd define a new special field OBJECT_PID. If this is included in a > > > > message, and that message comes from a privileged service, then > > > > journald > > > > will automatically add in OBJECT_EXE, OBJECT_UID, OBJECT_COMM, > > > > OBJECT_UNIT > > > > ... from /proc. > > OK, that would work too. How is "a privileged service" defined? > > As "not from a session cgroup" maybe? That would allow system services > that run under their own UID to make use of this functionality but > disallows this for user code. The same check is also used for splitting > off user journals: instead of simply splitting things up by UID we only > split up if the process has a session assigned, so that avahi and > friends (which run as avahi user) end up storing their stuff in the > system journal.
I don't think that this is safe. We want to prevent spoofing of messages by unpriviledged processes. So an apache daemon running in a service should not be allowed to generate messages which would be displayed in 'journalctl -u UNIT', where UNIT is something different than the apache.service. journald messages are supposed to be trustworthy, and I think this includes the assumption that the user doesn't have to use 'journalctl -o verbose' to check the provience of messages. Maybe we could add an explicit field AllowJournalSpoofing=yes/no, defaulting to no of course, and set it to yes for setroubleshootd and a few other special services. Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
