Loading a kexec kernel is guarded by CAP_SYS_BOOT, which we allow a container to have.
A container can't do 'kexec -e' to actually execute the new kernel, because that requires a call to reboot which is refused. However, it can do kexec -l do load a kernel for the next kexec -e. This means that it could race with an admin on the host doing 'kexec -l; kexec -e'. Exact command line used in the container:
There is a patch on lkml to prevent a task in non-init pid namespace (i.e. a container) from loading kexec kernels: https://lkml.org/lkml/2012/8/3/152. Please apply to precise and quantal.
After quantal, user namespaces will provide an alternative fix.
Loading a kexec kernel is guarded by CAP_SYS_BOOT, which we allow a container to have.
A container can't do 'kexec -e' to actually execute the new kernel, because that requires a call to reboot which is refused. However, it can do kexec -l do load a kernel for the next kexec -e. This means that it could race with an admin on the host doing 'kexec -l; kexec -e'. Exact command line used in the container:
sudo kexec -l /boot/vmlinuz- 3.5.0-5- generic --append= root=LABEL= cloudimg- rootfs --initrd= /boot/initrd. img-3.5. 0-5-generic
Before this, kexec -e on the host gives:
Nothing has been loaded!
After this, it loads the new kernel.
There is a patch on lkml to prevent a task in non-init pid namespace (i.e. a container) from loading kexec kernels: https:/ /lkml.org/ lkml/2012/ 8/3/152. Please apply to precise and quantal.
After quantal, user namespaces will provide an alternative fix.