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,...}.
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-58
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1+b1
ii libblkid1 2.25.2-4
ii libc6 2.19-13
ii libcap2 1:2.24-6
ii libcap2-bin 1:2.24-6
ii libcryptsetup4 2:1.6.6-4
ii libgcrypt20 1.6.2-4+b1
ii libkmod2 18-3
ii liblzma5 5.1.1alpha+20120614-2+b3
ii libpam0g 1.1.8-3.1
ii libselinux1 2.3-2
ii libsystemd0 215-8
ii mount 2.25.2-4
ii sysv-rc 2.88dsf-58
ii udev 215-8
ii util-linux 2.25.2-4
Versions of packages systemd recommends:
ii dbus 1.8.12-3
ii libpam-systemd 215-8
Versions of packages systemd suggests:
pn systemd-ui <none>
-- no debconf information
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: journald-make-syslog-work-without-cap-sys-admin.patch
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20150110/8dc44dda/attachment.ksh>