Quoting Martin Pitt ([email protected]): > The cap_audit_* are a lie, the audit subsystem in current kernels isn't
To be pedantic, it is not a lie - you have that capability against your own user namespace, but the only check for that capability is explicitly against the initial user namespace. But it certainly seems the easiest (short-term) workaround is to drop that capability. Unfortunately that will be tough coordinate with the (soon-coming) namespaced audit. If we drop it now in container configs, how do we tell userspace to re-enable it when available. The cleaner way from our pov would be for systemd to check using bind() whether it has the access. Then as soon as the kernel provided the ability to do that in a non-init userns, containers could use it. To put it another way, the check for capability bounding set is always explitily a check for capabilities against your user namespace. If the question is "can I read audit logs", then "do I have CAP_AUDIT_READ in my bounding set" is simply the wrong check. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1457054 Title: journal is broken in unprivileged LXC and nspawn containers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1457054/+subscriptions -- Ubuntu-server-bugs mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
