From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOUjZ-0007qe-Sj for qemu-devel@nongnu.org; Mon, 23 May 2011 08:59:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOUjX-0006Gg-Uo for qemu-devel@nongnu.org; Mon, 23 May 2011 08:59:45 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:53057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOUjX-0006GW-S2 for qemu-devel@nongnu.org; Mon, 23 May 2011 08:59:43 -0400 Received: by ywl41 with SMTP id 41so2441448ywl.4 for ; Mon, 23 May 2011 05:59:43 -0700 (PDT) Message-ID: <4DDA5A3C.1010500@codemonkey.ws> Date: Mon, 23 May 2011 07:59:40 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4DD6B777.9020800@us.ibm.com> <20110523094558.GA24143@redhat.com> <20110523103027.GD24143@redhat.com> In-Reply-To: <20110523103027.GD24143@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Stefan Hajnoczi , Tyler C Hicks , Corey Bryant , qemu-devel@nongnu.org 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 > Regards, > Daniel