On 2019-12-30 14:47, Ken Brown wrote: > On 12/30/2019 3:55 PM, Brian Inglis wrote: >> 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. > > Yes, but Cygwin doesn't claim to support the AT_EMPTY_PATH flag except in > linkat. So there is no expected errno. The only way there would be an > expected > errno is if we decide to add support for AT_EMPTY_PATH to fchownat. I'm > saying > that I don't see the point in doing that, and I'm asking whether I'm missing > something. If you think I should add that support, please explain why.
To allow perms changed on the cwd, directories or files with an open fd, to avoid race conditions, like the other ...at functions. I don't get why you don't see those as useful cases. -- 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.