From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbXoU-00026q-Hl for qemu-devel@nongnu.org; Fri, 27 Mar 2015 13:12:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbXoM-0006iB-7z for qemu-devel@nongnu.org; Fri, 27 Mar 2015 13:12:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbXoL-0006hl-WE for qemu-devel@nongnu.org; Fri, 27 Mar 2015 13:12:46 -0400 Message-ID: <55158F8B.9090607@redhat.com> Date: Fri, 27 Mar 2015 11:12:43 -0600 From: Eric Blake MIME-Version: 1.0 References: <55151DB7.3090200@msgid.tls.msk.ru> <55156DE0.4050209@redhat.com> <551578F4.9010400@msgid.tls.msk.ru> In-Reply-To: <551578F4.9010400@msgid.tls.msk.ru> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eMWx5AFxgn5NGtewdNJ1Weup2i0aNHxKX" Subject: Re: [Qemu-devel] block-commit & dropping privs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev , qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eMWx5AFxgn5NGtewdNJ1Weup2i0aNHxKX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/27/2015 09:36 AM, Michael Tokarev wrote: >> It is already possible to open a file read-write on the command line, = by >> using -add-fd twice to put both a read-only and a read-write fd handle= >> to the same file in a single set N, then using -drive options to speci= fy >> /dev/fdset/N rather than the file name. By that argument, I'm not sur= e >> if adding any other command line options is necessary. >=20 > How does fdSET work? How to use it? Will the BDS reopen work with an > fdset in an empty chroot? Basically, you can create an fdset that contains one or more fds. Any code in qemu that uses qemu_open() understands the magic pseudo-path of /dev/fdset/N as redirecting the open to instead find the first fd in that set that matches the requested permissions. So if an fdset contains both a read-only fd and a read-write fd, the set will dup() the appropriate fd back to the caller of qemu_open. Opening a drive is one of the places already wired up to use qemu_open. fdset manipulations can be done on both the initial command line (-add-fd along with open file descriptor inheritance) and in QMP (add-fd over the Unix socket with SCM_RIGHTS). As the fdset has access to already-open fds, it can access data even when open() will not succeed (such as in an empty chroot; but ALSO in the case of NVSv3 which lacks persistent SELinux labeling to affect open() but has no problem with per-fd labelling, and thus where fdset is supposed to allow out-of-the-box sandboxing without the current hack of 'setsebool virt_use_nfs off'). Note that fdsets have been in the code base for a couple of years now, but that most of it is still on the theory side (it SHOULD work) and not the practical side (libvirt isn't using them yet, although I want to eventually get there), so it will be nice if you can post actual working scenarios if you get it working. >=20 > Sorry I haven't seen this so far, and documentation is a bit vague. Yeah, that's certainly the case (and patches are of course welcome). >=20 > I think I see how this should work, monitor_fdset_get_fd() will search > an FD with matching access mode flags... Ok, so two fds in an fdset, > one ro and one rw. And with that in mind, since qemu_open() checks if > the filename starts with /dev/fdset/, it should work inside a chroot. Yep. >=20 > Wonder how to specify cache mode, or should I open these with proper > O_DIRECT/O_SYNC/whatever? It looks like it's possible to change O_DIRE= CT > at runtime but not O_SYNC. >=20 > And the more interesting question is how to do that from shell. Redirections only get you so far in shell; you may need a wrapper C program go get O_DIRECT and/or O_SYNC pre-set. Then again, if you use QMP and pass over the Unix socket, you need a C program anyways. >=20 > Oh well. Good luck! --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --eMWx5AFxgn5NGtewdNJ1Weup2i0aNHxKX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVFY+LAAoJEKeha0olJ0NqHKoH/jnVW6OZzh9eELNPRLzt8LjN 9+vLuCBGWdAf7VfuvsCElqa4edKl8m/A3ktz64qvro7TvOylE8fBtluovYEPM70O +yTegpQUHNVBiICQaE0xLD9+W+tf7Ped/ZqMEDCeyfBk3I2NKdnkaDzEjVO9mC/0 au9ZKaccCUD9Yf1AX/xZXLs9gfAoPepI2joa7FyvWyYa1NZP4NHWUD4VA3vymOAH 3qVT6oiCOGO6ldChJyGR5tLZuLxgpVUQbtTfmIoJDpYinUNiLvFcZlVHXgE8dqgC wIlBIWRr8RhgYXG+3vY/ZC89/bdiXnDNmURMl+DrbWCux/GfAQZ9MG87qty3a18= =6YCP -----END PGP SIGNATURE----- --eMWx5AFxgn5NGtewdNJ1Weup2i0aNHxKX--