mkfifo(1) creates fifos with incorrect permissions when the -m option is used. Fix: Patch: http://lamancha.opendarwin.org/~toby/freebsd/mkfifo.diff How-To-Repeat: Pretty much any usage of mkfifo -m will do it.
Responsible Changed From-To: freebsd-standards->rwatson Robert has been working a lot with FIFO's lately....
On Fri, 23 Sep 2005, Craig Rodrigues wrote: > Synopsis: [PATCH] mkfifo(1) uses wrong permissions > > Responsible-Changed-From-To: freebsd-standards->rwatson > Responsible-Changed-By: rodrigc > Responsible-Changed-When: Fri Sep 23 04:35:12 GMT 2005 > Responsible-Changed-Why: > Robert has been working a lot with FIFO's lately.... > > http://www.freebsd.org/cgi/query-pr.cgi?pr=86484 Our man page documents mkfifo(1) as interacting with umasks in two ways: (1) if -m is not used, then the requested mode is 0666 as influenced by the umask, and (2) if -m is used, the umask is ignored. In my basic testing here, it appeared to operate correctly on FreeBSD 7.x-CURRENT: peppercorn:/tmp/tmp> umask 22 peppercorn:/tmp/tmp> foreach mode (0600 0660 0666 0400 0440 0444 0200 0220 0222) foreach? mkfifo -m $mode $mode foreach? end peppercorn:/tmp/tmp> mkfifo nomode peppercorn:/tmp/tmp> ls -l total 12 drwxr-xr-x 2 robert wheel 512 Sep 23 08:59 ./ drwxrwxrwt 16 root wheel 10240 Sep 23 08:49 ../ p-w------- 1 robert wheel 0 Sep 23 08:59 0200| p-w--w---- 1 robert wheel 0 Sep 23 08:59 0220| p-w--w--w- 1 robert wheel 0 Sep 23 08:59 0222| pr-------- 1 robert wheel 0 Sep 23 08:59 0400| pr--r----- 1 robert wheel 0 Sep 23 08:59 0440| pr--r--r-- 1 robert wheel 0 Sep 23 08:59 0444| prw------- 1 robert wheel 0 Sep 23 08:59 0600| prw-rw---- 1 robert wheel 0 Sep 23 08:59 0660| prw-rw-rw- 1 robert wheel 0 Sep 23 08:59 0666| prw-r--r-- 1 robert wheel 0 Sep 23 08:59 nomode| So on face value, the behavior of the application matches the specification in mkfifo(1). The real question is whether mkfifo(1) matches some other important specification, like POSIX. Since I don't have POSIX.2 on hand, I can't comment on that. Robert N M Watson
State Changed From-To: open->feedback Change to feedback since I'd like either a clarification of how to reproduce the bug, or a clarification on why the man page (specification) isn't right.
On Fri, Sep 23, 2005 at 09:02:50AM +0100, Robert Watson wrote: > So on face value, the behavior of the application matches the > specification in mkfifo(1). The real question is whether mkfifo(1) > matches some other important specification, like POSIX. Since I don't > have POSIX.2 on hand, I can't comment on that. The latest POSIX specification for mkfifo is here: http://www.opengroup.org/onlinepubs/000095399/utilities/mkfifo.html As far as I can tell, FreeBSD is conforming to what is written there. -- Craig Rodrigues rodrigc@crodrigues.org
On Fri, 23 Sep 2005, Craig Rodrigues wrote: > On Fri, Sep 23, 2005 at 09:02:50AM +0100, Robert Watson wrote: >> So on face value, the behavior of the application matches the >> specification in mkfifo(1). The real question is whether mkfifo(1) >> matches some other important specification, like POSIX. Since I don't >> have POSIX.2 on hand, I can't comment on that. > > The latest POSIX specification for mkfifo is here: > http://www.opengroup.org/onlinepubs/000095399/utilities/mkfifo.html > > As far as I can tell, FreeBSD is conforming to what is written there. That's my reading also. Our mkfifo(1) man page is a little more specific about the interactions with umask(2), but I take it to mean the same thing in the end. Robert N M Watson
On Sep 23, 2005, at 4:47 AM, Robert Watson wrote: > > On Fri, 23 Sep 2005, Craig Rodrigues wrote: > > >> On Fri, Sep 23, 2005 at 09:02:50AM +0100, Robert Watson wrote: >> >>> So on face value, the behavior of the application matches the >>> specification in mkfifo(1). The real question is whether mkfifo(1) >>> matches some other important specification, like POSIX. Since I >>> don't >>> have POSIX.2 on hand, I can't comment on that. >>> >> >> The latest POSIX specification for mkfifo is here: http:// >> www.opengroup.org/onlinepubs/000095399/utilities/mkfifo.html >> >> As far as I can tell, FreeBSD is conforming to what is written there. >> > > That's my reading also. Our mkfifo(1) man page is a little more > specific about the interactions with umask(2), but I take it to > mean the same thing in the end. My original problem description wasn't very precise. I'll provide specific failure cases later today. - Toby
On Sep 23, 2005, at 4:47 AM, Robert Watson wrote: > > On Fri, 23 Sep 2005, Craig Rodrigues wrote: > > >> On Fri, Sep 23, 2005 at 09:02:50AM +0100, Robert Watson wrote: >> >>> So on face value, the behavior of the application matches the >>> specification in mkfifo(1). The real question is whether mkfifo(1) >>> matches some other important specification, like POSIX. Since I >>> don't >>> have POSIX.2 on hand, I can't comment on that. >>> >> >> The latest POSIX specification for mkfifo is here: http:// >> www.opengroup.org/onlinepubs/000095399/utilities/mkfifo.html >> >> As far as I can tell, FreeBSD is conforming to what is written there. >> > > That's my reading also. Our mkfifo(1) man page is a little more > specific about the interactions with umask(2), but I take it to > mean the same thing in the end. OK, here's some examples and POSIX quotes... -------- umask 027 mkfifo -m +x fifo Perms should be 'prwxrwxrw-' rather than 'prwxrwxrwx'. From http://www.opengroup.org/onlinepubs/000095399/utilities/ mkfifo.html : "The mode option-argument shall be the same as the mode operand defined for the chmod utility." From http://www.opengroup.org/onlinepubs/000095399/utilities/ chmod.html : "If who is not specified, the file mode bits represented by perm for the owner, group, and other permissions, except for those with corresponding bits in the file mode creation mask of the invoking process, shall be set." So, since the o+x bit is set in the umask, it shouldn't be set by mkfifo. -------- umask u=rwx,g=rx,o=x mkfifo -m -w another_fifo Perms should be 'pr--rw-rw-', not 'pr--r--r--'. Same argument as above applies. The go+w bits are set, so should not be cleared. -------- It occurs to me that this should be documented, and a check_utility_compat check should probably be added as well. Thoughts? - Toby
State Changed From-To: feedback->analyzed Seems like we have an understanding of the problem.
Responsible Changed From-To: rwatson->freebsd-standards Assign to freebsd-standards who may be interested in taking a hand in deciding what is the best way to fix this, and what the impact of moving to standards conformance would be.
POSIX's description of how umask interacts with -m for various tools is a maze of twisting little references, all different; it wouldn't surprise me if they meant something other than what they said. :) To take a step back, I would argue that mkfifo(1), mkdir(1), and install(1) should all have similar semantics with respect to -m, to reduce confusion. What those semantics are, I'm not sure. Solaris 10 seems to behave as FreeBSD does, and Linux 2.6.12 seems to behave as Toby Petersin wants FreeBSD to behave.
The link to the patch is broken :-(.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.