On Wed, Sep 04, 2002 at 01:13:28PM +0200, Ingo Molnar wrote:
>
> On Sun, 1 Sep 2002, Amos Waterland wrote:
>
> > That is the fundamental problem with a userspace shared memory
> > implementation: write permissions on a message queue should grant
> > mq_send(), but write permissions on shared memory grant a lot more than
> > just that.
>
> is it really a problem? As long as the read and write queues are separated
> per sender, all that can happen is that a sender is allowed to read his
> own messages - that is not an exciting capability.
Ingo:
I can see no way to keep the queues separated per sender if userspace
shared memory is used. The data structures used to keep track of the
messages must be writable by both the senders and receivers, because of
the kernel persistent nature of message queues: messages must stay in
the queue during the interval of arbitrary length between the sender
calling mq_send() and the receiver calling mq_receive().
That is, suppose process X posts message M, and then exits. Process Y
wants to receive message M, which means it must acquire a process-shared
lock and then remove M from the queue: so Y must be able to update the
data structures representing the queue. I see no way to allow Y to
update the data structures in shared memory without giving Y write
permission to the pages. If Y has write permission to the pages, it can
spoof messages/wreck the queue, etc. If you see a way around this,
please correct me. Thanks.
Ulrich/Jakub:
Is the above related to glibc's position that mq's will not go in until
there is kernel support? Thanks.
Amos Waterland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:31 EST