[Bug 1707901] Re: systemd-journald-audit.socket attempts to start in unpriviledged LXD container, but cannot

[Stéphane Graber]

You can look at /proc/self/uid_map to see if uid 0 is mapped to a non-0
uid, which would mean that you're not getting real root.

Root in an unprivileged container does hold all the capabilities, but those are tied to the user namespace so they're only useful if the resource you're trying to access is namespaced too.
The audit log isn't yet namespaced (there's work to have it be) so even though root does have the CAP_AUDIT_READ capability against the container it doesn't have it against the whole kernel.

For now, I'd say just make the unit skip in containers in general. Until
audit is namespaced, there's very little reason for a container, even
privileged, to interact with it.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1707901

Title:
  systemd-journald-audit.socket attempts to start in unpriviledged LXD
  container, but cannot

Status in lxd package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  systemd-journald-audit.socket attempts to start in unpriviledged LXD
  container, but cannot.

  It fails with resource. There are no interesting logs inside the
  container, or on the host.

  The socket unit is as below, and both conditions dopass for the
  unpriviledged container.

  [Unit]
  Description=Journal Audit Socket
  Documentation=man:systemd-journald.service(8) man:journald.conf(5)
  DefaultDependencies=no
  Before=sockets.target
  ConditionSecurity=audit
  ConditionCapability=CAP_AUDIT_READ

  [Socket]
  Service=systemd-journald.service
  ReceiveBuffer=128M
  ListenNetlink=audit 1
  PassCredentials=yes

  Are there any capabilities that are set/not-set for the priviledged
  /non-priviledged container in LXD? As in, are there any ways to
  distinguish between priviledge / unpriviledged container for which
  CAP_AUDIT_READ will in fact work or not?

  Currently ubuntu boots degraded inside unpriviledged lxd container,
  and that does not look nice. Or attempting to use a capability is the
  only way to know for sure?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1707901/+subscriptions