[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] block-commit & dropping privs
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] block-commit & dropping privs |
Date: |
Fri, 27 Mar 2015 11:12:43 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
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
signature.asc
Description: OpenPGP digital signature