From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfkcF-0005Al-AS for qemu-devel@nongnu.org; Mon, 20 Feb 2017 04:50:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cfkcB-000436-JV for qemu-devel@nongnu.org; Mon, 20 Feb 2017 04:50:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58492) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cfkcB-00042t-2i for qemu-devel@nongnu.org; Mon, 20 Feb 2017 04:50:39 -0500 Date: Mon, 20 Feb 2017 09:50:28 +0000 From: "Daniel P. Berrange" Message-ID: <20170220095028.GC15874@redhat.com> Reply-To: "Daniel P. Berrange" References: <20170217214215.GK19045@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ketan Nilangekar Cc: Jeff Cody , ashish mittal , qemu-devel , Paolo Bonzini , Kevin Wolf , Markus Armbruster , Fam Zheng , Ashish Mittal , Stefan Hajnoczi , John Ferlan , Buddhi Madhav , Suraj Singh , Nitin Jerath , Peter Maydell , Abhijit Dey , "Venkatesha M.G." , Rakesh Ranjan On Sat, Feb 18, 2017 at 12:30:31AM +0000, Ketan Nilangekar wrote: > On 2/17/17, 1:42 PM, "Jeff Cody" wrote: > > On Thu, Feb 16, 2017 at 02:24:19PM -0800, ashish mittal wrote: > > Hi, > > > > I am getting the following error with checkpatch.pl > > > > ERROR: externs should be avoided in .c files > > #78: FILE: block/vxhs.c:28: > > +QemuUUID qemu_uuid __attribute__ ((weak)); > > > > Is there any way to get around this, or does it mean that I would have > > to add a vxhs.h just for this one entry? > > > > I remain skeptical on the use of the qemu_uuid as a way to select the TLS > cert. > > [ketan] > Is there another identity that can be used for uniquely identifying instances? > The requirement was to enforce vdisk access to owner instances. The UUID is a bad way to do any kind of access control as QEMU could simply lie about its UUID. If the server needs to identify the client to do access control you need something non-spoofable. In the absence of having an authentication protocol built into the libqnio protocol, the best you could do would be to use the TLS client certificate distinguished name. QEMU can't lie about that without having access to the other certificate file - which would be blocked by SELinux Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|