[PATCH v2 0/3] Support opening a symlink with O_PATH | O_NOFOLLOW
Mon Jan 13 18:37:00 GMT 2020
On 1/13/20 11:44 AM, Ken Brown wrote:
>>> 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?
Without actually writing a test program on Linux, I'm not sure.
Logically, I'd expect that changing the owner of a symlink is a metadata
operation that affects the containing directory rather than the contents
of the file, but that access to the directory entry is what O_PATH is
supposed to provide, and therefore it seems like fchownat() on an empty
filename should work the same as lchownat(). But if it fails in Linux,
then we don't have to do any better.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
More information about the Cygwin-patches