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

Brian Inglis Brian.Inglis@SystematicSw.ab.ca
Mon Dec 30 20:54:00 GMT 2019


On 2019-12-30 12:53, Ken Brown wrote:
> 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?

That is the user's problem: it is their responsibility to pass an fd open for
reading or searching, not one opened with O_PATH (on Linux or Cygwin), or
AT_FDCWD; it is Cygwin's responsibility to ensure that valid args succeed and
invalid args return the expected errno.

$ man fchownat
...
"EBADF  The path argument does not specify an absolute path and
	the fd argument is neither AT_FDCWD nor a valid file descriptor
	open for reading or searching."

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.



More information about the Cygwin-patches mailing list