Hello, I've noticed in the msgctl(2) manpage that a condition to get an EPERM error code was dropped in the past : it's about trying to modify the size of a message queue (msg_qbytes) larger than the max size set in kernel (look at /proc/sys/kernel/msgmnb). In a (very old) manpage of a Debian Woody 3.0 (!), we could read : EPERM The argument cmd has value IPC_SET or IPC_RMID but the calling process effective user-ID has insufficient privileges to execute the command. Note this is also the case of a non super-user process trying to increase the msg_qbytes value beyond the value specified by the system parameter MSGMNB. thereas on later pages (on my Debian Wheezy 7.4, but also in current version of kernel manpages), we only have : EPERM The argument cmd has the value IPC_SET or IPC_RMID, but the effective user ID of the calling process is not the creator (as found in msg_perm.cuid) or the owner (as found in msg_perm.uid) of the message queue, and the process is not privileged (Linux: it does not have the CAP_SYS_ADMIN capability). Could you put back in the man page a sentence like : 'Note this is also the case of a non super-user process trying to increase the msg_qbytes value beyond the value specified by the system parameter MSGMNB.' Thanks, Frédéric.
(In reply to Frédéric Boiteux from comment #0) > Hello, > > I've noticed in the msgctl(2) manpage that a condition to get an EPERM > error code was dropped in the past : it's about trying to modify the size of > a message queue (msg_qbytes) larger than the max size set in kernel (look at > /proc/sys/kernel/msgmnb). > > In a (very old) manpage of a Debian Woody 3.0 (!), we could read : > > EPERM The argument cmd has value IPC_SET or IPC_RMID but the > calling process effective user-ID has insufficient privileges to > execute the command. Note this is also the case of a > non super-user process trying to increase the msg_qbytes value > beyond the value specified by the system parameter MSGMNB. > > > thereas on later pages (on my Debian Wheezy 7.4, but also in current version > of kernel manpages), we only have : > > EPERM The argument cmd has the value IPC_SET or IPC_RMID, but the > effective user ID of the calling process is not the creator (as found in > msg_perm.cuid) or the owner (as found in msg_perm.uid) of the > message queue, and the process is not privileged (Linux: it does not have > the CAP_SYS_ADMIN capability). > > > Could you put back in the man page a sentence like : 'Note this is also the > case of a non super-user process trying to increase the msg_qbytes value > beyond the value specified by the system parameter MSGMNB.' > Yes, it is puzzling that that text was dropped. It was done back in 1.51, before the days of version control or mailing lists for man-pages, so I can't divine the reason. Nevertheless, elsewhere in the page, it notes that a capability is required to raise this value above MSGMNB. (And there was a typo in that text, where it mentioned CAP_IPC_RESOURCE; should be CAP_SYS_RESOURCE; fixed now). So, obviously, a fix is required. I applied the patch below. Thanks for your report. diff --git a/man2/msgctl.2 b/man2/msgctl.2 index e092fcb..ea39e10 100644 --- a/man2/msgctl.2 +++ b/man2/msgctl.2 @@ -311,6 +311,17 @@ of the message queue, and the process is not privileged (Linux: it does not have the .B CAP_SYS_ADMIN capability). +.TP +.B EPERM +An attempt +.RB ( IPC_SET ) +was made to increase +.I msg_qbytes +beyond the system parameter +.BR MSGMNB , +but the caller is not privileged (Linux: does not have the +.B CAP_SYS_RESOURCE +capability). .SH CONFORMING TO SVr4, POSIX.1-2001. .\" SVID does not document the EIDRM error condition.