[RFC][PATCH 0/8][v2]: Enable multiple mounts of devpts
Cedric Le Goater
clg at fr.ibm.com
Wed Sep 3 06:52:11 PDT 2008
>>> 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
>>> 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
This make sense
More information about the Containers