#1977 mq_open lacks support of "mode" argument

[Joel Sherrill]

On Wed, Feb 5, 2020, 12:58 AM Bran S <archsbran at gmail.com> wrote:

> Trying to solve ticket https://devel.rtems.org/ticket/1977
>
> The mode parameter sets access permissions for the created message queue.
> Examples:
> S_IRUSR  00400 user has read permission
> S_IWUSR  00200 user has write permission
> S_IXUSR  00100 user has execute permission
> Complete list is at: http://man7.org/linux/man-pages/man2/open.2.html
>
>
> https://github.com/RTEMS/rtems/blob/master/cpukit/posix/src/mqueueopen.c#L176
> Is this is the place where we need to take care of the mode argument ?
>
> I am thinking we would need to store the mode bits in
> POSIX_Message_queue_Control structure.(Ref:
>
> https://github.com/RTEMS/rtems/blob/master/cpukit/include/rtems/posix/mqueue.h#L57
> )
>
> Then every time the created queue is accessed we would use the mode
> bits to check if the accessor is allowed to access the queue.
>

POSIX mqs are specified to have file like attributes but do not have to be
filesystem objects. In RTEMS, they are not.

That only leaves two places to add this. The score and the POSIX control
structure for mqs. I'm prone to agree with you that this is POSIX specific
and requires the mq descriptors.

But please make sure this even makes sense inside a single process. In a
full POSIX system there can be multiple processes accessing the mq and the
mode may make sense in that use case.

It may require our capability to set a different per process environment
for a thread to get different user and group IDs for testing.

Just thinking in terms of when an access gets rejected, what were the
ownership, gid and uid for the mq versus the accessing attempt.


> Please share your thoughts on solving this.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200205/58a1b3dd/attachment.html>