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

[Ken Brown <kbrown at cornell dot edu>]

On 12/30/2019 2:18 PM, Brian Inglis wrote:
> On 2019-12-29 10: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.
>>
>> According to the Linux man page for 'open', the file descriptor
>> returned by the call should be usable as the dirfd argument in calls
>> to fstatat and readlinkat with an empty pathname, to have
>> the calls operate on the symbolic link.  The second and third patches
>> achieve this.  For fstatat, we do this by adding support
>> for the AT_EMPTY_PATH flag.
>>
>> 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.
>>
>> Am I missing something?
> 
> WSL $ man 2 chown
> ...
> "AT_EMPTY_PATH (since Linux 2.6.39)
> If pathname is an empty string, operate on the file referred to
> by dirfd (which may have been obtained using the open(2) O_PATH
> flag). In  this case, dirfd can refer to any type of file, not
> just a directory. If dirfd is AT_FDCWD, the  call operates on
> the current working directory. This flag is Linux-specific; de‐
> fine _GNU_SOURCE to obtain its definition."
> 
> says chown the dirfd, regardless of what it is,
> except if AT_FDCWD, chown the CWD.
> 
> WSL $ man 2 open
> "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
> operations 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."
> 
> O_PATH does not open the file, so fchown returns EBADF,
> as it requires an fd of an open file.

I think you've just confirmed what I already said: If fchownat is called with 
AT_EMPTY_PATH, with an empty pathname, and with dirfd referring to a file that 
was opened with O_PATH, then fchownat will fail with EBADF.

So for the purposes of this patch series, I don't see the point of adding 
support for AT_EMPTY_PATH in fchownat.

Am I missing something?

Ken