Date: Fri, 04 Oct 2024 18:00:57 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 243177] open(2): Add O_CREATFIFO flag Message-ID: <bug-243177-227-NLxAmhIFLn@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-243177-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243177 Brooks Davis <brooks@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brooks@FreeBSD.org Status|Open |Closed Resolution|--- |Not A Bug Version|12.0-RELEASE |Unspecified --- Comment #2 from Brooks Davis <brooks@FreeBSD.org> --- What is the threat model? The purpose of a fifo is to rendezvous via the file system which is inherently subject to races. Creating and opening the fifo atomically is all well and good, but something else with the right permissions could just delete the fifo and create a new one in its place leaving a half open fifo to nowhere. If race-free communication is required, socketpair(2) and fork(+execve) is probably a better choice. If it still makes sense to implement something like this, it's worth noting that we're quite close to running out of bits for new O_ flags. A new syscall (e.g., open_fifo_at(2)) might be a better option. If we did this we'd want to build some consensus among various POSIX system implementors before implementing something. The FreeBSD bug database probably isn't the place to do that so I'm closing this feature request. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-243177-227-NLxAmhIFLn>