Date: Tue, 13 Sep 2005 11:21:57 GMT From: Robert Watson <rwatson@FreeBSD.org> To: dlt@mebtel.net, rwatson@FreeBSD.org, rwatson@FreeBSD.org Subject: Re: kern/74242: Write to fifo with no reader fails in 6.0 current Message-ID: <200509131121.j8DBLvpe016661@freefall.freebsd.org> Resent-Message-ID: <20050913122335.G23515@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509131121.j8DBLvpe016661>