[PATCH v2 0/3] Support opening a symlink with O_PATH | O_NOFOLLOW

Brian Inglis Brian.Inglis@SystematicSw.ab.ca
Mon Dec 30 19:18:00 GMT 2019


On 2019-12-29 10:56, Ken Brown wrote:
> Currently, opening a symlink with O_NOFOLLOW fails with ELOOP.
> Following Linux, the first patch in this series allows the call to
> succeed if O_PATH is also specified.
> 
> According to the Linux man page for 'open', the file descriptor
> returned by the call should be usable as the dirfd argument in calls
> to fstatat and readlinkat with an empty pathname, to have
> the calls operate on the symbolic link.  The second and third patches
> achieve this.  For fstatat, we do this by adding support
> for the AT_EMPTY_PATH flag.
> 
> Note: The man page mentions fchownat and linkat also.  linkat already
> supports the AT_EMPTY_PATH flag, so nothing needs to be done.  But I
> don't understand how this could work for fchownat, because fchown
> fails with EBADF if its fd argument was opened with O_PATH.  So I
> haven't touched fchownat.
> 
> Am I missing something?

WSL $ man 2 chown
...
"AT_EMPTY_PATH (since Linux 2.6.39)
If pathname is an empty string, operate on the file referred to
by dirfd (which may have been obtained using the open(2) O_PATH
flag). In  this case, dirfd can refer to any type of file, not
just a directory. If dirfd is AT_FDCWD, the  call operates on
the current working directory. This flag is Linux-specific; de‐
fine _GNU_SOURCE to obtain its definition."

says chown the dirfd, regardless of what it is,
except if AT_FDCWD, chown the CWD.

WSL $ man 2 open
"O_PATH (since Linux 2.6.39)
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."

O_PATH does not open the file, so fchown returns EBADF,
as it requires an fd of an open file.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.



More information about the Cygwin-patches mailing list