Serge E. Hallyn wrote: > Quoting Eric W. Biederman ([EMAIL PROTECTED]): >> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes: >> >>>> (3.2) mnt namespace maybe ? >>> I think the last one is the way to go. >>> >>> mnt_namespace points to mq_ns. >>> >>> At clone(CLONE_NEWMNT), the new mnt namespace receives a copy of the >>> parent's mq_ns. >>> >>> If a task does >>> mount -o newinstance -t mqueue none /dev/mqueue >>> then its current->nsproxy->mnt_namespace->mqns is switched >>> to point to a new instance of the mq_ns. >>> >>> mnt_ns->mq_ns has pointers to the sb (and hence root dentry) of the >>> devpts fs. >>> >>> When a task does mq_open(name, flag), then name is in the mqueuefs >>> found in current->nsproxy->mnt_namespace->mqns. >>> >>> But if a task does >>> >>> clone(CLONE_NEWMNT); >>> mount --move /dev/mqueue /oldmqueue >>> mount -o newinstance -t mqueue none /dev/mqueue >>> >>> then that task can find files for the old mqueuefs under >>> /oldmqueue, while mq_open() uses /dev/mqueue since that's >>> what it finds through its mnt_namespace. >> Serge if we can make the lookup a pure mount namespace operation >> i.e. a well known path. Than I don't have any problems with it. >> Otherwise it looks like abuse of the mount namespace. > > Why? > > Actually it may work to just put mq_ns straight in the nsproxy.
ok. that's the path I was taking. > So let's see: > > mq_open(name, flag): opens name under the dentry pointed > to by current->nsproxy->mq_ns->mq_dentry > mount -t mqueue none /dev/mqueue: either returns -EBUSY > or just mounts current->nsproxy->mq_ns->mq_sb > under /dev/mqueue > mount -o newinstance -t mqueue none /dev/mqueue: mounts > a new mq_ns instance under /dev/mqueue > > While doing > mount --make-rshared /vs1 > mount --bind /dev/mqueue /vs1/dev/mqueue > create_a_new_container_chrooted_at(/vs1) > mount -o newinstance -t mqueue none /dev/mqueue > would allow the host to see the child's /dev/mqueue under > /vs1/dev/mqueue while having its own mqueuefs continue to be > mounted under /dev/mqueue. ok. complete isolation would require 2 steps. I guess this is acceptable because mq uses a fs allowing the host to see the child's /dev/mqueue is also 'a nice to have' feature. unfortunately, we can't do that for all namespaces, for sysvipc for example. So I'm wondering if we should allow it at all ? Thanks, C. _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
