lkml.org 
[lkml]   [2017]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2017-04-19 16:04    [W:0.093 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site