From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOWE0-0000EI-QS for qemu-devel@nongnu.org; Mon, 23 May 2011 10:35:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOWDz-0000Hx-Mx for qemu-devel@nongnu.org; Mon, 23 May 2011 10:35:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOWDz-0000Ht-Bp for qemu-devel@nongnu.org; Mon, 23 May 2011 10:35:15 -0400 From: Markus Armbruster References: <4DD6B777.9020800@us.ibm.com> <20110523094558.GA24143@redhat.com> <20110523103027.GD24143@redhat.com> <4DDA5A3C.1010500@codemonkey.ws> Date: Mon, 23 May 2011 16:35:10 +0200 In-Reply-To: <4DDA5A3C.1010500@codemonkey.ws> (Anthony Liguori's message of "Mon, 23 May 2011 07:59:40 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , Tyler C Hicks , Corey Bryant , qemu-devel@nongnu.org Anthony Liguori writes: > On 05/23/2011 05:30 AM, Daniel P. Berrange wrote: >> It feels to me that turning the current block driver code which just does >> open(2) on files, into something which issues events& asynchronously >> waits for a file would potentially be quite complex. >> >> You also need to be much more careful from a security POV if the mgmt >> app is accepting requests to open arbitrary files from QEMU, to ensure >> the filenames are correctly/strictly validated before opening them and >> giving them back to QEMU. An architecture where the mgmt app decides >> what FDs to supply upfront, has less potential for security errors. >> >> To me the ideal would thus be that we can supply FDs for the backing >> store with -blockdev syntax, and that places where QEMU re-opens files >> would be enhanced to avoid that need. If there are things we can't do >> without closing& re-opening the same file, then perhaps we need some >> new ioctl()/fcntl() calls to change those file attributes on the fly. > > I agree. But my view of blockdev is that you wouldn't set an fd > attribute but rather the backing file name and use the fd protocol. > For instance: > > -blockdev id=foo-base,path=fd:4,format=raw > -blockdev id=foo,path=fd:3,format=qcow2,backing_file=foo I guess you mean backing_file=foo-base. If none is specified, use the backing file specification stored in the image. Matches my current thinking.