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
Description: Make journald syslog fwd'ing work w/o CAP_SYS_ADMIN
In case CAP_SYS_ADMIN is missing, one cannot fake pid in struct ucred
(uid/gid are find if CAP_SETUID/CAP_SETGID are present), which is the
case in some container setups.
.
This patch makes sure that journald will try again to forward the
messages to syslog, without faking the SCM_CREDENTIALS pid this time
(which isn't guaranteed anyway, since it also does the same thing if
the process has already exited).
.
With this patch, journald will no longer silently discard messages
that are supposed to be sent to syslog in these situations.
Author: Christian Seiler <christ...@iwakd.de>
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: systemd-215/src/journal/journald-syslog.c
===================================================================
--- systemd-215.orig/src/journal/journald-syslog.c
+++ systemd-215/src/journal/journald-syslog.c
@@ -85,12 +85,12 @@ static void forward_syslog_iovec(Server
return;
}
- if (ucred && errno == ESRCH) {
+ if (ucred && (errno == ESRCH || errno == EPERM)) {
struct ucred u;
/* Hmm, presumably the sender process vanished
- * by now, so let's fix it as good as we
- * can, and retry */
+ * by now, or we don't have CAP_SYS_AMDIN, so
+ * let's fix it as good as we can, and retry */
u = *ucred;
u.pid = getpid();
