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

[Corinna Vinschen]

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.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20200113/6935402f/attachment.sig>