From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbWJ9-0005HD-NH for qemu-devel@nongnu.org; Fri, 27 Mar 2015 11:36:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbWJ5-0006z1-MP for qemu-devel@nongnu.org; Fri, 27 Mar 2015 11:36:27 -0400 Received: from isrv.corpit.ru ([86.62.121.231]:35647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbWJ5-0006yr-E5 for qemu-devel@nongnu.org; Fri, 27 Mar 2015 11:36:23 -0400 Message-ID: <551578F4.9010400@msgid.tls.msk.ru> Date: Fri, 27 Mar 2015 18:36:20 +0300 From: Michael Tokarev MIME-Version: 1.0 References: <55151DB7.3090200@msgid.tls.msk.ru> <55156DE0.4050209@redhat.com> In-Reply-To: <55156DE0.4050209@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] block-commit & dropping privs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel 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. >