Date: Wed, 19 Apr 2017 14:45:00 +0200
From: Greg Kurz <groug@kaod.org>
To: Colin Walters <walters@verbum.org>
Cc: Eric Blake <eblake@redhat.com>, viro@zeniv.linux.org.uk,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] vfs: implement fchmodat2() syscall
Message-ID: <20170419144500.76f93360@bahia.lab.toulouse-stg.fr.ibm.com>
In-Reply-To: <1491937780.536443.941636728.319DEAF0@webmail.messagingengine.com>
References: <148830142269.7103.7429913851447595016.stgit@bahia>
        <99466bd0-48f2-1594-5392-5e6191d56ffa@redhat.com>
        <1491933162.45759.941552624.3722F8E8@webmail.messagingengine.com>
        <02954403-b546-0afe-39c7-23b7b05dece2@redhat.com>
        <9005445d-2a56-effd-55da-b3bc700c5cf2@redhat.com>
        <1491937780.536443.941636728.319DEAF0@webmail.messagingengine.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 boundary="Sig_/UZFfS3QcLA+U.rN5qF/=jIX"; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2595
Lines: 82

--Sig_/UZFfS3QcLA+U.rN5qF/=jIX
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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:
> >=20
> > 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. =20
>=20
> Right, though more topically I'd have expected
> fchmodat() (not fchmod()) to take AT_EMPTY_PATH,
> just like fstatat() does.
>=20

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:
>=20
> int
> fchmodat (int fd, const char *file, mode_t mode, int flag)
> {
>   if (flag & ~AT_SYMLINK_NOFOLLOW)
>     return INLINE_SYSCALL_ERROR_RETURN_VALUE (EINVAL);
> ...
> }
>=20
> 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.
>=20
>=20

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

--Sig_/UZFfS3QcLA+U.rN5qF/=jIX
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlj3W8wACgkQAvw66wEB28JiTwCfb5WOeHCWljjRo/fpNrEwfCAe
fhQAnR30vmyyUZO1zsmZSuU6WrNblalZ
=0Z5t
-----END PGP SIGNATURE-----

--Sig_/UZFfS3QcLA+U.rN5qF/=jIX--