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

[Michael Tokarev]

27.03.2015 17:49, Eric Blake wrote:
> On 03/27/2015 03:07 AM, Michael Tokarev wrote:
>> Hello.
>>
>> I tried to experiment with block-commit command, which propagates
>> changes accumulated in an overlay (qcow2) block image file back to
>> the base image file.
>>
>> And immediately faced a problem.  All my VMs are run chrooted into
>> an empty dir and with low-priv user (using -runsa and -chroot options,
>> initially started as root).  Ofcourse this low-priv qemu process
>> can't open the base image anymore, because it doesn't have the
>> necessary permissions and because the base file is inaccessible
>> within the chroot.
>>
>> So I wonder if we can avoid reopening the base img by always opening
>> it read-write (using a command-line option), does it make sense?
> 
> 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?

Sorry I haven't seen this so far, and documentation is a bit vague.

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.

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.

Oh well.

Thanks,

/mjt


>> Or maybe there's some other possible solution to this, for example,
>> passing in a filedescriptor for the new base img over a unix socket?
> 
> Hmm, we do allow QMP to pass in fds over Unix sockets already, but what
> we don't have yet is the ability to associate one of those just-passed
> fds to an existing open BDS (right now, you can only create a new fdset
> as tied to a new BDS, but block-commit can only target an open BDS;
> there is no way to pivot which BDS base is associated with another BDS).
>  So maybe there is still room for improvement, especially since having a
> QMP solution is nicer than requiring foresight to pass in an fdset from
> the command line.
>