[systemd-devel] [PATCH] journal: don't complain about audit socket errors in a container.

[Frank Thalberg]

Hi Lennart,

thank you very much for reviewing and responding to the mess I made.
Hopefully it will be a smoother experience from now on.

On Mon, 13 Apr 2015 16:08:28 +0200
lennart at poettering.net (Lennart Poettering) wrote:

> What kind of containers are these? LXC? docker?

I guess I failed describing the scenario properly.  I was trying
to run a fresh Archlinux installation inside a subdirectory via the
systemd-nspawn -b -D ... command on a debian host.  No Docker, LXC or
any other software was involved.  Just plain systemd tools and a bio
blob between chair and keyboard.

I was toying around with systemd-nspawn.  It seems to me as a
smoother implementation of that whole container idea compared to docker
for example because it directly boots into systemd and properly
initializes services and other environment related resources like the
machine-id file within /etc/.  It's also quiet nice to have systemd to
handle the init daemon and logging tasks.  The other solutions leave you
on your own here.

> nspawn at least grants audit caps to containers. If you don't grant
> audit caps you cannot boot distros like Fedora at all, since much of
> the PAM audit code in Fedora is written to fail completely if audit
> is on in the kernel, but cannot be used.

My first impression was that container/namespaces aren't supported
inside the audit kernel code at all.  Someone at the #archlinux channel
on freenode gave this hint and I also thought this way because the
kernel source at
<https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/kernel/audit.c?h=linux-3.16.y#n653>
looks this way.  But at a closer look it doesn't seem to me like that
anymore mostly because the returned error at the given line differs
from the error I'm experiencing (ECONNREFUSED vs. EPERM).  It rather
seems that the "offending" line is
<https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/kernel/audit.c?h=linux-3.16.y#n1115>.

I still have to butt in though.  There are 2 issues here at hand. 

The first one: It doesn't look to me like the audit subsystem within the
kernel is ready for namespaces.  They aren't directly rejected but I
can't see any measurements to separate namespaces.  It would be quiet
unfortunate if processes within a namespace could receive audit events
from another namespace. 

The second problem is rather simple: it seems libcap currently doesn't
understand the CAP_AUDIT_READ value so passing it to the --capability=
option is not an (easy) option.

Given that I would suggest to treat the whole audit subsystem to be
optional and don't fail too hard if it can't be used. Unfortunately
pre-built packages can't offer the option to configure this behavior.

> Hmm, exluding the audit code from the build if HAVE_AUDIT is not set
> is certainly a good idea, but we generally try to keep #ifdeffery out
> of .c files. More specifically, the journald-audit.c file should not
> be compiled and linked at all on non-audit builds, and
> journald-audit.h should contain the #ifdeffery that causes
> server_open_audit() to become a NOP on such builds. Would be happy to
> take a patch for that.

Can't agree more with you here.  Your solution to the problem is a
little more work than I was initially willing to invest into the
problem.  I'll gladly provide a better patch for this given the
the interest in handling this.

Thank you very much for reading this lengthy mail, I'm looking forward
to your response!


Greetings,
Frank.