[lxc-devel] seccomp, lxcfs and force-unmount

Serge Hallyn serge.hallyn at ubuntu.com
Wed Jul 29 02:29:33 UTC 2015


Quoting Wolfgang Bumiller (w.bumiller at proxmox.com):
> (I only recently subscribed to the list so forgive me if there's already
> a thread I should be replying to instead of opening a new one.)
> 
> So I came across the force-unmount issue where `umount -f` on any of the
> bind mounts can cause lxcfs on the host to terminate.
> 
> I find the seccomp solution to be rather crude as force-unmount might
> have some legitimate usecases inside a container, and the seccomp way
> cannot be limited to certain paths. And it's still problematic with 32
> bit containers on 64 bit hosts, as mentioned in #571 due to
> reject_force_umount being incorrectly resolved to systemcalls (and
> getting equal -1 IDs from it).
> I'd like to know why this is even necessary, as I don't see a reason to
> care about IDs since as far as I can tell you _do_ need to add them to
> both contexts.  (Which is what I do in my pull request #600 - awaiting

Oh, thanks, I'll look at that.  (I don't generally see pull requests,
so for lxc, unlike for lxd, patches to the m-l are often, but not always,
better)

> review/comments).
> 
> Here's the idea/suggestion:
> I'm wondering if it would instead make sense to spawn an lxcfs process
> per container. If this is problematic due to lxcfs' design the only
> other way I see to support force-unmount inside containers would be to
> spawn a bindfs (fuse bind) per container between the container and
> lxcfs, in which case the force-unmount would only terminate the bind,
> rather than the lxcfs itself.
> 
> Either way I'd be willing to work on some patches if I know which
> direction to go.

Two possible directions for solving this are,

https://bugs.launchpad.net/apparmor/+bug/1403968 - having apparmor
policy dictate based on path whether the force-umount should be
allowed

kernel - if there are other existing mounts of the same source that
is being force-umounted, and any come from a user_ns which is a
ancestor of the one doing the umount, it could be rejected.

thanks,
-serge


More information about the lxc-devel mailing list