(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 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. _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
