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

[Ken Brown <kbrown at cornell dot edu>]

On 1/13/2020 1:39 PM, Corinna Vinschen wrote:
> 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...

OK, I'll follow your first suggestion, then, after verifying that fchownat 
really does work on a symlink opened this way on Linux.  I guess I was 
misinterpreting the man page.

Ken