Re: [Qemu-devel] block-commit & dropping privs

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]

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 specify
>> /dev/fdset/N rather than the file name.  By that argument, I'm not sure
>> if adding any other command line options is necessary.
> 
> 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.

> 
> 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).

> 
> 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.

> 
> 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_DIRECT
> at runtime but not O_SYNC.
> 
> 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.

> 
> Oh well.

Good luck!

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]