On Thu, Dec 08, 2011 at 03:34:48PM +0000, Daniel P. Berrange wrote: > On Thu, Dec 08, 2011 at 07:14:41AM -0800, Chris Haumesser wrote: > > Chris Haumesser wrote: > > > Am I misinterpreting the output of getpcaps then? (getpcaps is rather > > > undocumented). > > > > Answering my own question, I was misinterpreting the output of getpcaps. > > I found the cap_from_text(3) man page, which explained the output format. > > > > I still don't understand why I was able to reboot the host from within a > > container, however. > > Well I just confirmed (the hard way!) that you are correct. It is possible > to reboot the host from inside the container, despire CAP_SYS_REBOOT > being blocked. I'll try & figure out how that's happening/possible... It is obvious in retrospect. If you have a container which is sharing the host OS's root filesystem, then it can see the host's /dev which contains a /dev/initctrl FIFO pipe. The 'reboot' command can tell the host OS to shutdown via that pipe, thus lack of CAP_SYS_REBOOT is irrelevant. Since this is a FIFO and not a blockdev/chardev we can't use cgroups to prevent access to /dev/initctrl. The only reliable way is to wait for the kernel's user namespace stuff. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
