>> >> (3) move mq_ns out of nsproxy. where shall I put it then ? >> >> (3.1) task_struct ? >> (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. hmm, hmm, hmm, I still thinking about this. > 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. [trying to understand what you have in mind ] why not keep the 'struct vfsmount' in the mq_ns, as the code is doing today ? the vfsmount holds both the root dentry and the superblock. > 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. That I don't like. Even though posix mqueue objects can outlive a process, I don't think a process should be able to peek and poke in a message queue namespace other than his. this is the basic principle of the namespaces : isolation. Am I wrong ? couldn't we just return EACCES ? (not posix) C. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers