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 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list