From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbQEX-0002ZS-Ju for qemu-devel@nongnu.org; Fri, 27 Mar 2015 05:07:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbQER-00011j-0q for qemu-devel@nongnu.org; Fri, 27 Mar 2015 05:07:17 -0400 Received: from isrv.corpit.ru ([86.62.121.231]:54901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbQEQ-0000yT-Ov for qemu-devel@nongnu.org; Fri, 27 Mar 2015 05:07:10 -0400 Message-ID: <55151DB7.3090200@msgid.tls.msk.ru> Date: Fri, 27 Mar 2015 12:07:03 +0300 From: Michael Tokarev MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] block-commit & dropping privs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel 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? 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? Thanks, /mjt