What is the meaning and purpose of GID/UID bits on POSIX message queues?

Calling mq_open() with octal mode 2000 or 4000 (bitwise OR'd with the other mode bits) applies GID / UID bits to the mode bits of the queue name when examined using ls().

If the corresponding 'x' bit is set ...

Mode 2000 changes the group execute bit from 'x' to 's'.
Mode 4000 changes the owner execute bit from 'x' to 's'.

If the corresponding 'x' bit is NOT set ...

Mode 2000 changes the group execute bit from ' ' to 'S'.
Mode 4000 has no effect.

Do these 's' / 'S' bits do anything?

Edit: I thought these were sticky() bits but as SirDice points out, they're not.
 
Mode 1000 changes the group execute bit from 'x' to 's'.
Mode 2000 changes the owner execute bit from 'x' to 's'.
Shouldn't that be 2000 for the set group ID bit and 4000 for the set user ID bit? Looks like your mask is shifted one bit to the right.

Code:
           #define S_ISUID 0004000    /* set user id on execution */
           #define S_ISGID 0002000    /* set group id on execution */
           #define S_ISVTX 0001000    /* sticky bit */
chmod(2)
 
Updated the question. This is what I was looking at by creating queue names with all eight possible bit combinations:

Code:
-rwxr-xr-x   1 ordinary wheel  0 Feb  5 12:22 T0755
-rwxr-xr-x   1 ordinary wheel  0 Feb  5 12:22 T1755
-rwxr-sr-x   1 ordinary wheel  0 Feb  5 12:22 T2755
-rwxr-sr-x   1 ordinary wheel  0 Feb  5 12:22 T3755
-rwsr-xr-x   1 ordinary wheel  0 Feb  5 12:22 T4755
-rwsr-xr-x   1 ordinary wheel  0 Feb  5 12:22 T5755
-rwsr-sr-x   1 ordinary wheel  0 Feb  5 12:22 T6755
-rwsr-sr-x   1 ordinary wheel  0 Feb  5 12:22 T7755
 
If the corresponding 'x' bit is NOT set ...

Mode 2000 changes the group execute bit from ' ' to 'S'.
Mode 4000 has no effect.

Do these 's' / 'S' bits do anything?
Not entirely sure I'm not missing something subtle in your post, I think that they do:
Code:
[gunsynd.193] $ touch x
[gunsynd.194] $ ls -lad x
-rw-r--r--  1 phil  wheel  0 Feb  6 09:15 x
[gunsynd.195] $ chmod 4644 x
[gunsynd.196] $ ls -lad x
-rwSr--r--  1 phil  wheel  0 Feb  6 09:15 x
[gunsynd.197] $ chmod 4755 x
[gunsynd.198] $ ls -lad x
-rwsr-xr-x  1 phil  wheel  0 Feb  6 09:15 x
[gunsynd.199] $ chmod 6644 x
[gunsynd.200] $ ls -lad x
-rwSr-Sr--  1 phil  wheel  0 Feb  6 09:15 x
[gunsynd.201] $ chmod 6755 x
[gunsynd.202] $ ls -ald x
-rwsr-sr-x  1 phil  wheel  0 Feb  6 09:15 x
The chmod(1) manual describes the (modern) meanings and use of the 02000 and 04000 bits.

For directories, the 02000 and 04000 bits force inheritance on group and user ownership respectively when a new file (of any kind) is created in the directory, e.g. for a group inheritance:
Code:
[gunsynd.181] $ id
uid=1001(phil) gid=1001(phil) groups=1001(phil),0(wheel)
[gunsynd.182] $ mkdir d
[gunsynd.183] $ ls -lad d
drwxr-xr-x  2 phil  wheel  2 Feb  6 09:06 d
[gunsynd.184] $ sudo chgrp daemon d
[gunsynd.185] $ chmod g+s d
chmod: d: Operation not permitted
[gunsynd.186] $ sudo chmod g+s d
[gunsynd.187] $ ls -lad d
drwxr-sr-x  2 phil  daemon  2 Feb  6 09:06 d
[gunsynd.188] $ touch d/f
[gunsynd.189] $ ls -al d
total 2
drwxr-sr-x  2 phil  daemon  3 Feb  6 09:07 .
drwxr-xr-x  3 phil  wheel   3 Feb  6 09:06 ..
-rw-r--r--  1 phil  daemon  0 Feb  6 09:07 f
 
Not entirely sure I'm not missing something subtle in your post, I think that they do:
Thank you. This adds some clarity along with new questions.

chmod() claims these bits are intended for executable files. My hunch is these don't do anything in the context of a POSIX message queue.
 
chmod() claims these bits are intended for executable files. My hunch is these don't do anything in the context of a POSIX message queue.
The manual says:
Code:
           4000    (the setuid bit). Executable files... [deleted]
                   Directories with this bit set will force all files and sub-
                   directories created in them to be owned by the directory
                   owner and not by the uid of the creating process, if the
                   underlying file system supports this feature: see chmod(2)
                   and the suiddir option to mount(8).
This is demonstrated in the second code fragment posted above.
 
For the sake of the informative sections (e. g. programming examples) I like to consult the actual POSIX™ documents. There mq_open says
[…] When bits in mode other than the file permission bits are specified, the effect is unspecified. […]
The term file permission bits is defined in the base definitions part:​
[…] The bits are divided into three parts: owner, group, and other. […]
So from a POSIX™ point of view, the meaning of 06000 is undefined. This, of course, does not prevent an implementer (here FreeBSD kernel programmers) to assign meaning nevertheless.​
 
The manual says:
Code:
           4000    (the setuid bit). Executable files... [deleted]
                   Directories with this bit set will force all files and sub-
                   directories created in them to be owned by the directory
                   owner and not by the uid of the creating process, if the
                   underlying file system supports this feature: see chmod(2)
                   and the suiddir option to mount(8).
This is demonstrated in the second code fragment posted above.
Right. Apologies for not being clear. To clarify - I am asking about what, if any, effect these bits have on POSIX message queues which are not files and not directories (and not streams or device nodes).
 
Some background for anyone following along.

This is required:


# kldload mqueuefs


This is optional:


# mount -t mqueuefs null /mount/point


Of course, ls() is only possible if the file system is mounted.
 
Side note: I'm creating a utility called 'posixmqcontrol' - in the spirit of posixshmcontrol() so I'm hashing out some of the finer points of POSIX MQs.

POSIXMQCONTROL(1) FreeBSD General Commands Manual POSIXMQCONTROL(1)

NAME
posixmqcontrol – Control POSIX mqueuefs message queues

SYNOPSIS
posixmqcontrol create [-q queue] [-s size] [-d depth] [-m mode]
posixmqcontrol info [-q queue]
posixmqcontrol recv [-q queue]
posixmqcontrol rm [-q queue]
posixmqcontrol send [-q queue] [-p payload]

DESCRIPTION
The posixmqcontrol command manipulates the named POSIX message queue. It
allows creating queues, inspecting their metadata, dumping contents, and
unlinking them.

Unlinking removes the name from the system and frees underlying memory.

The maximum message size, maximum queue size, and current queue depth are
displayed by the info subcommand. This output is similar to running cat
on a mqueuefs queue mounted under a mount point. This utility requires
mqueuefs kernal module to be loaded but does not require mqueuefs to be
mounted as a file system.

The following subcommands are provided:

create Create the named queues, if they do not already exist. More
than one queue name may be created. The same depth and size are
used to create all queues.

The required size and depth arguments specify the maxmimum
message size and maxmimum message depth. The optional
numerical mode argument specifies the initial access mode.

rm Unlink the queues specified - one attempt per queue. Failure to
unlink one queue does not stop this sub-command from attempting
the others.

info For each named queue, dispay the maximum message size, maximum
queue size, and current queue depth.

recv Wait for a message from a single named queue and display the
message to standard output.

SUMMARY
posixmqcontrol allows you to move POSIX message queue administration out
of your applications. Adjusting queue attributes can be done without
touching application code.

EXIT STATUS
The posixmqcontrol utility exits 0 on success, and >0 if an error occurs.

EXAMPLES
• To retrieve the current message from a named queue, "/1", use the
command
posixmqcontrol recv -q /1

• To create a queue with the name "/2" with message size 100 and maximum
queue depth 10, use the command
posixmqcontrol create -q /2 -s 100 -d 10

• To send a message to a queue with the name "/3" use the command
posixmqcontrol send -q /3 -p 'some choice words.'

• To examine attributes of a queue named "/4" use the command
posixmqcontrol info -q /4

SEE ALSO
mq_open(2), mq_getattr(2), mq_send(2), mq_receive(2), mq_unlink(2),
mqueuefs(5)

FreeBSD 14.0-RELEASE-p3 February 5, 2024 FreeBSD 14.0-RELEASE-p3
 
Great idea. My release scope is set but someone could unify all IPC related APIs.
The ipcmk/ipcs/ipcrm tool do this for SysV IPC.

On Linux I noticed a GTK app using 0666 perms for its shared memory and I ended up developing the equivalent chmod to it in the form of ipcmod. I also wanted to know the memory contents and did shmdump. It only works on Linux though:
 
Back
Top