[systemd-devel] [PATCH] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]

[Lennart Poettering]

On Wed, 20.05.15 13:53, Martin Pitt (martin.pitt at ubuntu.com) wrote:

> -                        cached_use = true;
> +                        /* bind() fails in namespaces (containers), so check that too */
> +                        static const union sockaddr_union sa = {
> +                                .nl.nl_family = AF_NETLINK,
> +                                .nl.nl_pid    = 0,
> +                                .nl.nl_groups = AUDIT_NLGRP_READLOG,
> +                        };
> +                        cached_use = (bind(fd, &sa.sa, sizeof(sa.nl)) >= 0);
>                          safe_close(fd);

This check is simply not right. With that you check whether the
multicast audit API is available. But given that it has been added
only one or two kernel releases ago, and is protected by its own
capabality the check is definitely too broad.

The fact is simply that the kernel audit subsystem is borked in the
kernel when it comes to namespacing, and there's no nice way to detect
whether it is borked I am aware of. 

And it's not really about this multicast journald feature only. Sooner
or later you will run into other problems: any fedora-based distro
will not allow you to even log in in the container if you leave audit
on in the kernel, and don#t use the seccomp hack we have in place (for
example, because you are on 32bit x86, or because your distro turned
it off).

We could of course add a detect_container() check now to journald. But
I think that would be a big mistake, since there was work on fixing
audit in the kernel for containers (by adding audit namespacing or
so). And we should try to write our code so that things will start
working when the kernel is fixed, but a detect_container() check would
make that impossible.

Anyway, I think people are mostly concerned about bind() failing here,
hence I have now added some code to handle that gracefully.

Right now it will still log a message with LOG_WARNING. I'd be willing
to downgrade this to LOG_DEBUG for select error codes, if you tell me
the ones you run into. EINVAL?

Also, please convince your distro to enable seccomp support!

Lennart

-- 
Lennart Poettering, Red Hat