Messages in this thread | | | Date | Wed, 19 Apr 2017 14:45:00 +0200 | From | Greg Kurz <> | Subject | Re: [PATCH 1/2] vfs: implement fchmodat2() syscall |
| |
On Tue, 11 Apr 2017 15:09:40 -0400 Colin Walters <walters@verbum.org> wrote:
> On Tue, Apr 11, 2017, at 02:07 PM, Eric Blake wrote: > > > > A good idea on the surface. But reading the man page of openat(), the > > section on O_PATH says: > > The file > > itself is not opened, and other file operations (e.g., > > read(2), > > write(2), fchmod(2), fchown(2), fgetxattr(2), mmap(2)) > > fail with > > the error EBADF. > > Right, though more topically I'd have expected > fchmodat() (not fchmod()) to take AT_EMPTY_PATH, > just like fstatat() does. >
Like Eric said in another mail, this would still require to open() the file first... ie, we cannot change mode if initial bits are 0000, whereas it succeeds with chmod().
> But it doesn't appear to be supported...oh, even at > the syscall level, interesting. Ah, I see, glibc does: > > int > fchmodat (int fd, const char *file, mode_t mode, int flag) > { > if (flag & ~AT_SYMLINK_NOFOLLOW) > return INLINE_SYSCALL_ERROR_RETURN_VALUE (EINVAL); > ... > } > > And indeed the syscall doesn't have flags, bringing us back > to the start here. Sorry, that seems obvious in retrospect, > but I was "working forwards" from the O_PATH userspace API > mindset. > >
The use case is to fix CVE-2016-9602 in QEMU. We need to be able to change the mode bits of a file that resides under a specific directory, which is shared between the host and the guest.
Since untrusted code in a guest can create symlinks, we need to be sure that the file isn't a symlink, otherwise the mode bit change could affect an arbitrary file not residing under the shared directory.
This could be handled with chroot() or unshare()+chdir() but this isn't an option because we want this to work even if QEMU is unprivileged.
According to POSIX, this is exactly how fchmodat(AT_SYMLINK_NOFOLLOW) should behave on Linux:
[EOPNOTSUPP] The AT_SYMLINK_NOFOLLOW bit is set in the flag argument, path names a symbolic link, and the system does not support changing the mode of a symbolic link.
I hope this is clear enough.
-- Greg [unhandled content-type:application/pgp-signature] | |