kern/74242: Write to fifo with no reader fails in 6.0 current

[Robert Watson]

Synopsis: Write to fifo with no reader fails in 6.0 current

State-Changed-From-To: open->feedback
State-Changed-By: rwatson
State-Changed-When: Tue Sep 13 11:10:48 GMT 2005
State-Changed-Why: 
When I run the "tick" and "speak" programs as described, I get EBADF back
from the read() call in "tick", as open() has failed, which results from
mknod() failing with EPERM.  This somewhat obscure failure mode was due
to a lack of error checking in the test programs, which didn't confirm
that the fifo had been created or opened before attempting I/O on the
returned descriptor.  If run sequentially, "tick" actually does work,
since "speak" calls mkfifo(), which succeeds.  When the mknod() call in
"tick" is replaced with mkfifo(), the tests appear to operate correctly
on recent 7.x.  When I ran the test programs as provided on 4.x, they
failed, but worked with the mkfifo change.

There appears to be some disagreement about whether mknod(S_FIFO) should
work for unprivileged users.  FreeBSD 4.x does not permit this.  FreeBSD
6.x and 7.x do not permit this.  It could well be that FreeBSD 5.x does
permit this.  POSIX indicates that privilege is required for non-S_FIFO,
but appears to allow mknod(2) as an acceptable interface to create fifos
as an unprivileged user.  It could be that we should broaden the scope
of mknod(2) to require privilege only for non-fifo objects, in order to
provide more portable support for fifos.

Could you confirm that, in your environment, the source of the read()
error is in fact that mknod() has failed (detected by checking for a
return value of -1, and then printed using err(-1, "mknod")), and that
if the fifo is created using mkfifo(), "tick" operates properly in your
environment?  This would help us identify that there isn't another bug
lurking here.

FYI, it could be that FreeBSD 5.3 appeared to allow this by virtue of
the fact that the order in which the provided programs are run is quite
significant in how they operate: later runs of "tick" will work fine as
the fifo has been created by a prior run of "speak", and then not been
removed.

Thanks,

Robert Watson


http://www.freebsd.org/cgi/query-pr.cgi?pr=74242