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
