[systemd-devel] Client logging to journald without libsystemd-journal.so

[Daniel P. Berrange]

On Thu, Nov 08, 2012 at 04:56:03PM -0500, Colin Walters wrote:
> Sorry about the tone in the last message, it was unnecessary.  There's
> just some history here dating from the libxml2 days...

No worries, no offence taken :-)

> On Thu, 2012-11-08 at 17:38 +0100, Daniel P. Berrange wrote:
> 
> > Yeah, we've looked at & borrowed code from GLib in a few cases
> > now, notably threads and atomic ops. I've previously looked at
> > GLib's process spawning code, but didn't notice this particular
> > item. Originally we did have an API fairly similar to the
> > g_spawn_async_with_pipes API, but it is proved fairly cumbersome
> > to use, so we've put together a much more flexible API now [1].
> 
> Yeah, I've been working on a new one:
> https://bugzilla.gnome.org/show_bug.cgi?id=672102
> 
> > Possible, though I feel it is a little nasty, not least because when
> > when journald then uses SCM_CREDS to find out the sender identity it
> > will be getting the wrong pid and potentially wrong uid/gid too.
> 
> This is an interesting case...conceptually it's true that it's a new
> pid, but I think it's a lot more useful usually what *code* it's
> running; ordinarily, that'd be an executable.  But here we're running
> code from the parent just before executing a new child. 
> 
> Pretty much any error in fork-before-exec should be fatal, right?  So in
> the case where you're logging an error (e.g. setuid()
> failed, prctl() failed), the pid is going to be irrelevant anyways
> since the process will soon exit.

Hmm, good point.

> The uid/gid - yes, but on the other hand, the uid associated with
> the message will be the one that's conceptually "in control" at the
> moment.

It is a tricky question really. If the code failed because it did
not have permission to open the file, and the log contains the uid
of the parent process, this could mislead the person analysing. At
the same time I see your point that the uid/gid/pid should refer to
the process "in control" which is the parent.

> Regardless though of the approach taken (log from parent, log from
> forked-before-exec'd child), it'd probably be good to include some
> standard structured field saying that the code is being run in a child
> setup.  "PREEXEC=1"? 

If the log is sent from the child, you'd really want to also include
the PID of the parent process, to allow the log messages to be directly
correlated. A shame SCM_CREDS doesn't directly provide the parent-PID
too

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|