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... Corinna -- Corinna Vinschen Cygwin Maintainer
signature.asc
Description: PGP signature