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