My previous change to LXC container capabilties setup has a fairly stupid bug in it. The container init process starts off with no capabilities whatsoever :-( This was caused by a bogus capng_lock() call which meant that all capabilities were cleared when the init process was exec'd. The capng_lock call sets NOROOT & NROOT_LOCKED flags in the process secure bits. This is not neccessary for the init process - we have reduced the bounding set which is sufficient for our security goals. With the capng_lock() call removed, the init process gets its permitted and effective sets filled to match the bounding set which is the desired scenario. Daniel diff --git a/src/lxc_container.c b/src/lxc_container.c index 950dd50..b3978df 100644 --- a/src/lxc_container.c +++ b/src/lxc_container.c @@ -675,16 +675,9 @@ static int lxcContainerDropCapabilities(void) _("failed to apply capabilities: %d"), ret); return -1; } - - /* Need to prevent them regaining any caps on exec */ - if ((ret = capng_lock()) < 0) { - lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR, - _("failed to lock capabilities: %d"), ret); - return -1; - } - #else - VIR_WARN0(_("libcap-ng support not compiled in, unable to clear capabilities")); + /* Don't warn, since this ends up going to the guest console and annoying admins + VIR_WARN0(_("libcap-ng support not compiled in, unable to clear capabilities")); */ #endif return 0; } -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|