[systemd-devel] Fwd: journald doesn't forward messages to syslog w/o CAP_SYS_ADMIN (LXC)

Martin Pitt mpitt at debian.org
Tue Jan 13 03:05:17 PST 2015


Hello all,

I'm forwarding a bug report about journal forwarding in containers
without CAP_SYS_ADMIN. I adjusted Christian's patch for current git
master and to be in git am format.

Thanks for considering,

Martin

----- Forwarded message from Christian Seiler <christian at iwakd.de> -----

Date: Sat, 10 Jan 2015 23:42:57 +0100
From: Christian Seiler <christian at iwakd.de>
To: Debian Bug Tracking System <submit at bugs.debian.org>
Subject: Bug#775067: systemd: journald doesn't forward messages to syslog w/o CAP_SYS_ADMIN (LXC)

Package: systemd
Version: 215-8
Severity: grave
Tags: upstream patch
Justification: causes non-serious data loss

Dear Maintainer,

when using LXC containers without CAP_SYS_ADMIN, journald fails to
forward any messages to syslog by default. Since the journal is not
persistent by default, no logs are stored at all, hence the
classification as 'data loss'. Also, this is a regression from Wheezy,
where a container without CAP_SYS_ADMIN and syslog did indeed store
persistent logs in /var/log/{syslog,messages,...}.

Note that there is NO other problem with systemd related to missing
CAP_SYS_ADMIN in a container (that I have found so far), provided all
required (pseudo-) file systems are mounted beforehand (which can be
done by configuration with Jessie's LXC version). I do know that
upstream claims that CAP_SYS_ADMIN-less containers are currently not
really supported, but they do intend to work towards that, and, from
what I can tell, apart from this journald problem, I have found no
issue whatsoever with a missing CAP_SYS_ADMIN (it actually works even
better than under sysvinit because it doesn't try to do some stuff
it's not supposed to do in containers that cause error messages with
sysvinit) - and since these kinds of containers were working in
Wheezy with its default init, I think this should be supported in
Jessie, too, especially if the fix is really easy, see below.

This bug is independent of the syslog implementation used, because no
syslog implementation in Jessie supports reading directly from the
journal, as far as I can tell (syslog-ng is too old, rsyslog is built
without imjournal support), so all rely on ForwardToSyslog=yes.

The reason why this problem occurs is that journald tries to fake
SCM_CREDENTIALS before sending a packet to the syslog daemon. With
CAP_SETUID and CAP_SETGID, faking uid/gid is not a problem, but to fake
the pid in struct ucred, one needs CAP_SYS_ADMIN (according to current
kernel source).

Also note that without activating debugging in journald, this problem
can not be diagnosed easily (it took me a while with strace to find the
problem).

Note, however, two things:

 - journald does (and can) not guarantee that it can fake the pid,
   because the process could have already exited. If you look at the
   source, in case ESRCH is returned, it just fakes uid/gid and uses
   its own pid

 - both rsyslog and syslog-ng (haven't tried anything else yet) don't
   rely on SCM_CREDENTIAL's pid anyway in their default configuration,
   so at least in the default configuration there's no reason to fail
   in that case.

I have created (and tested) an absolutely trivial patch that fixes this
by not only checking for ESRCH but also EPERM and then avoid faking the
pid.

I have tested this with both rsyslog and syslog-ng and it works and
both store (the same ;-)) persistent log messages in
/var/log/{messages,syslog,...}.


----- End forwarded message -----

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-journal-Fix-syslog-forwarding-without-CAP_SYS_ADMIN.patch
Type: text/x-diff
Size: 1667 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150113/a407002a/attachment.patch>


More information about the systemd-devel mailing list