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

[Ken Brown]

On 1/13/2020 12:24 PM, Eric Blake wrote:
> On 1/13/20 10:53 AM, Ken Brown wrote:
>> On 1/13/2020 10:28 AM, Corinna Vinschen wrote:
>>> Hi Ken,
>>>
>>> On Dec 29 17: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.
>>>>
> 
>>>
>>>    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.
>>>     ^^^^^^^^^           ^^^^^
>>>
> 
> On BSD systems, you are able to run lchmod to change permissions on a symlink 
> (with effect on who is able to follow that symlink during pathname resolution); 
> Linux does not support that, and POSIX does not mandate support for that, so 
> fchmodat() is allowed to fail on symlinks even while fchownat() is required to 
> work on symlinks.
> 
>>> 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.
>>
>> I don't know why they include fchownat here, since the resulting call would fail
>> with EBADF.  So I didn't implement that in my patch series.
> 
> I'm not sure if the question here is about fchownat() (where you CAN change 
> owner of a symlink on Linux, same as with lchown())

Yes, the question is about fchownat.  Are you saying you can change the owner 
even if the symlink was opened with O_PATH?

Ken