On 2020-02-12, Florian Weimer <fw@xxxxxxxxxxxxx> wrote: > * Al Viro: > > > On Wed, Feb 12, 2020 at 08:15:08PM +0100, Florian Weimer wrote: > > > >> | Further, I've found some inconsistent behavior with ext4: chmod on the > >> | magic symlink fails with EOPNOTSUPP as in Florian's test, but fchmod > >> | on the O_PATH fd succeeds and changes the symlink mode. This is with > >> | 5.4. Cany anyone else confirm this? Is it a problem? > >> > >> It looks broken to me because fchmod (as an inode-changing operation) > >> is not supposed to work on O_PATH descriptors. > > > > Why? O_PATH does have an associated inode just fine; where does > > that "not supposed to" come from? > > It fails on most file systems right now. I thought that was expected. > Other system calls (fsetxattr IIRC) do not work on O_PATH descriptors, > either. I assumed that an O_PATH descriptor was not intending to > confer that capability. Even openat fails. openat(2) failing on an O_PATH for a symlink is separate to fchmod(2) failing: * fchmod(2) fails with EBADF because O_PATH file descriptors have f->f_ops set to empty_fops -- this is why ioctl(2)s also fail on O_PATH file descriptors. This is *intentional* behaviour. My understanding of the original idea of O_PATH file descriptors is that they are meant to have restricted capabilities -- it's effectively a "half-open" file handle. The fact that some folks (like myself) figured out you can do all sorts of crazy stuff with them is mostly an accident. * openat(n, ...) fails with ENOTDIR because openat(2) requires the argument to be a directory, and O_PATH-of-a-symlink-to-a-directory doesn't count (path_init doesn't do resolution of the dirfd argument -- nor should it IMHO). * open(/proc/self/fd/$n) failing with ELOOP might actually be a bug (the error is coming from may_open as though the lookup was done with O_NOFOLLOW) -- the nd_jump_link() jump takes the namei lookup to a the symlink but it looks like the normal link_path_walk et al handling doesn't actually try to continue resolving it. I'll look into this a bit more. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
