Commit aa55d22c, "Cygwin: honor the O_PATH flag when opening a FIFO",
fixed a hang but otherwise didn't accomplish the purpose of the O_PATH
flag as stated in the Linux man page for open(2):

    Obtain a file descriptor that can be used for two purposes: to
    indicate a location in the filesystem tree and to perform
    operations that act purely at the file descriptor level.  The
    file itself is not opened, and other file operations (e.g.,
    read(2), write(2), fchmod(2), fchown(2), fgetxattr(2),
    ioctl(2), mmap(2)) fail with the error EBADF.

    [The man page goes on to describe operations that *can* be
    performed: close(2), fchdir(2), fstat(2),....]

    Opening a file or directory with the O_PATH flag requires no
    permissions on the object itself (but does require execute
    permission on the directories in the path prefix).

The first problem in the current implementation is that if open(2) is
called on a FIFO, fhandler_base::device_access_denied is called and
tries to open the FIFO with read access, which isn't supposed to be
required.  This is fixed by the first patch in this series.

The second patch makes fhandler_fifo::open call fhandler_base::open_fs
if O_PATH is set, so that we actually obtain a handle that can be used
for the purposes stated above.

The third page tweaks fhandler_fifo::fcntl and fhandler_fifo::dup so
that they work with O_PATH.

In a followup email I'll provide the program I used to test this
implementation.

Ken Brown (3):
  Cygwin: device_access_denied: return false if O_PATH is set
  Cygwin: re-implement fhandler_fifo::open with O_PATH
  Cygwin: FIFO: tweak fcntl and dup when O_PATH is set

 winsup/cygwin/fhandler.cc      |  3 +++
 winsup/cygwin/fhandler_fifo.cc | 15 ++++++---------
 2 files changed, 9 insertions(+), 9 deletions(-)

-- 
2.21.0

Reply via email to