On 1/13/2020 1:39 PM, Corinna Vinschen wrote: > On Jan 13 19:34, Corinna Vinschen wrote: >> On Jan 13 16:53, Ken Brown wrote: >>> On 1/13/2020 10:28 AM, Corinna Vinschen wrote: >>>> On Dec 29 17:56, Ken Brown wrote: >>>>> [...] >>>>> 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. >>>> >>>> It was never supposed to work that way. We can make fchownat work >>>> with AT_EMPTY_PATH, but using it on a file opened with O_PATH >>>> contradicts the Linux open(2) man page, afaics: >>>> >>>> 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. >>>> ^^^^^^^^^ ^^^^^ >>>> >>>> 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. >> >> That's the part I missed, apparently. Implementing fchownat like this >> may be a bit upside down. The problem is that open(O_PATH) opens the >> file with query_read_attributes (aka READ_CONTROL | FILE_READ_ATTRIBUTES), >> to make sure the calls mentioned in the snippet I pasted don't succeed. >> >> If fchownat is supposed to work on a symlink like this, the easiest >> approach may be checking for this scenario in fchownat and calling >> lchown on the pathname instead. Or something along these lines. > > The alternative would be to open the sylink with more permissions, i.e., > query_write_control, aka READ_CONTROL | WRITE_OWNER | WRITE_DAC | > FILE_WRITE_ATTRIBUTES. I'm just hesitant to open up the descriptor > like this. It probably allows too many actions on the descriptor > from user space...
OK, I'll follow your first suggestion, then, after verifying that fchownat really does work on a symlink opened this way on Linux. I guess I was misinterpreting the man page. Ken