Re: [Xen-devel] [PATCH 1/2] libxl: correctly list disks served by driver domains in block-list

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

> +    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).

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.


> +        rc = libxl__xs_read_checked(gc, XBT_NULL, fe_path, &be_path);
> +        if (rc)
> +            goto out_err;
> +        rc = libxl__device_disk_from_xs_be(gc, be_path, &disks[*num]);
> +        if (rc)
> +            goto out_err;
> +        (*num)++;
> +        assert(*num <= xs_num);
> +    }
>  
> +out:
>      GC_FREE;
>      return disks;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel