From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: Re: [PATCH 1/2] libxl: correctly list disks served by driver domains in block-list Date: Tue, 10 Sep 2013 14:06:57 +0200 Message-ID: <522F0B61.4050400@citrix.com> References: <1378463786-16230-1-git-send-email-roger.pau@citrix.com> <1378463786-16230-2-git-send-email-roger.pau@citrix.com> <1378807909.21748.75.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VJMil-0000LU-H6 for xen-devel@lists.xenproject.org; Tue, 10 Sep 2013 12:07:03 +0000 In-Reply-To: <1378807909.21748.75.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xenproject.org, Ian Jackson List-Id: xen-devel@lists.xenproject.org On 10/09/13 12:11, Ian Campbell wrote: > On Fri, 2013-09-06 at 12:36 +0200, Roger Pau Monne wrote: >> The block-list command was not able to lists disks with backends >> running on domains different than Dom0, because it was only looking on >> the backend xenstore path of Dom0. Fix this by instead fetching the >> disks from the DomU xenstore entries. > > Need to be a bit careful here about reading from potentially guest > controllable keys. This should mostly be a question of permissions. > >> + fe_path = libxl__sprintf(gc, "/local/domain/%d/device/vbd", domid); > > Are guests able to create new subdirectories under here? Yes > >> + devs = libxl__xs_directory(gc, XBT_NULL, fe_path, &xs_num); >> + if (!devs) >> + /* Domain has no disks */ >> + goto out; >> + disks = libxl__calloc(NOGC, xs_num, sizeof(*disks)); >> + if (!disks) >> + goto out_err; >> + for (i = 0; i < xs_num; i++) { >> + fe_path = GCSPRINTF("/local/domain/%d/device/vbd/%s/backend", >> + domid, devs[i]); > > Is this path writeable by the guest? The containing directory is I > think, so this needs to include delete and recreate type situations > (although ISTR xenstore not having the posix like semantics here). Yes, the whole directory including the backend entry is writeable by the guest. > > If the guest can remove and recreate then we should check the current > owner of the key is e.g. the toolstack domain or whoever should be > trusted to won the key, within the same transaction as the read itself. I'm sorry but I'm not following you here, I assume you are speaking about the frontend node that points to the backend ie: /local/domain//device/vbd//backend Permissions on this node are: domid: perms: 0 domid: 0 perms: 1 If the guest changes this node, or recreates it permissions will still be the same.