[PATCH v2 0/3] Support opening a symlink with O_PATH | O_NOFOLLOW
Mon Jan 13 18:34:00 GMT 2020
On Jan 13 16:53, Ken Brown wrote:
> On 1/13/2020 10:28 AM, Corinna Vinschen wrote:
> > On Dec 29 17:56, Ken Brown wrote:
> >> [...]
> >> 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.
> > It was never supposed to work that way. We can make fchownat work
> > with AT_EMPTY_PATH, but using it on a file opened with O_PATH
> > contradicts the Linux open(2) man page, afaics:
> > 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 opera‐
> > tions 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.
> > ^^^^^^^^^ ^^^^^
> > That'd from the current F31 man pages.
> >> Am I missing something?
> > Good question. Let me ask in return, did *I* now miss something?
> I don't think so. I think we agree, although maybe I didn't express myself
> clearly enough for that to be obvious. What confused me was the following
> paragraph further down in the open(2) man page (still discussing O_PATH):
> If pathname is a symbolic link and the O_NOFOLLOW flag is also
> specified, then the call returns a file descriptor referring
> to the symbolic link. This file descriptor can be used as the
> dirfd argument in calls to fchownat(2), fstatat(2), linkat(2),
> and readlinkat(2) with an empty pathname to have the calls
> operate on the symbolic link.
That's the part I missed, apparently. Implementing fchownat like this
may be a bit upside down. The problem is that open(O_PATH) opens the
file with query_read_attributes (aka READ_CONTROL | FILE_READ_ATTRIBUTES),
to make sure the calls mentioned in the snippet I pasted don't succeed.
If fchownat is supposed to work on a symlink like this, the easiest
approach may be checking for this scenario in fchownat and calling
lchown on the pathname instead. Or something along these lines.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Cygwin-patches