[lxc-users] bind-mounting kernel directories

[Fajar A. Nugraha]

On Tue, Apr 7, 2015 at 5:57 AM, Marco <foobar.angus at gmail.com> wrote:

>> >  From your 'think/hope' comment it sounded like you were expecting
>> > something besides CAP_SYS_ADMIN to be able to stop the remount, but I'm
>> > not sure what that mechanism would be.
>>
>> No...  The old OLD problem was that if you mounted it RO, a container
>> could remounted it RW (or vice versa), which was one thing, but then,
>> under certain conditions and file systems, that change would be
>> propagated to the host and to other containers.

>
> On Debian at least, it still has some problems as I've reported here on the
> ML: Deb 8 && Lxc 1.0.6.
> An host fs, configured to be bind-mounted ro in the guest is actually
> accessible as rw (in the guest).
> The guest can than remount it as ro, but than the host fs becomes ro!
> Clearly not a desirable event.

You can backport lxc-1.0.7 from experimental.

Or better yet, compile lxc-1.1.1 yourself as well as lxcfs-0.7, which
brings (among others) better support for systemd-based containers.



On Wed, Apr 1, 2015 at 11:07 PM, Chris Burroughs
<chris.burroughs at gmail.com> wrote:
> Userland tools can be confused if the running kernel does not match anything
> in /lib/modules, and 'per-container' modules are nonsensical notion anyway.
> Is there any reason not to ready only bind-mount /lib/modules &
> /usr/src/kernels from the host into the container?  I've seen a few
> references in blogs but this does not appear to be the default behavior of
> the templates.
>

When I think about it, this requirement doesn't make sense for newer setups:
- default config (at least in ubuntu) includes lxc.cap.drop =
mac_admin mac_override sys_time sys_module, which prevents module
loading. A good thing, since allowing that could mean root user in
container loading malicious kernel modules which could bring down the
system.

- containers can run just fine even without kernel package installed
inside it. At least that's the case with ubuntu and centos 7
containers (possibly others as well)

The only use case that I can think of to having /lib/modules and
/usr/src/kernels inside a container is if you're going to using it for
module development, in which case you'd have to install other packages
as well (e.g. build-essential), and you won't need the same kernel
version as the one currently running.

-- 
Fajar