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

[Corinna Vinschen]

On Jan 13 19:34, Corinna Vinschen wrote:
> 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.

The alternative would be to open the sylink with more permissions, i.e.,
query_write_control, aka READ_CONTROL | WRITE_OWNER | WRITE_DAC |
FILE_WRITE_ATTRIBUTES.  I'm just hesitant to open up the descriptor
like this.  It probably allows too many actions on the descriptor
from user space...


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/0f503d87/attachment.sig>