>>> 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 ? > > Yes you are wrong in this case. In particular consider mounts > propagation, which allows you to to examine both a child namespace's > mounts namespace, and, through the child's /sys (presumably > mounted under /vs1/sys), his network namespace and eventually > device namespace. but there are some accounting done which could be fooled, like the max number of mqueues or the number of bytes used by the mqueues which is on a user_struct basis. >> couldn't we just return EACCES ? (not posix) > > We could. And if we think there is really no value in viewing > a child namespace's mqueuefs then we may as well. I just want > to make it clear that the proposed semantics support it as an > option. This make sense C. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
