Re: [Xen-devel] [PATCH 1/2] libxl: do not assume Dom0 backend while listing disks and nics

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-05-01 at 21:52 +0100, Marek Marczykowski wrote:
> On 01.05.2013 12:29, Ian Jackson wrote:
> > Marek Marczykowski writes ("[PATCH 1/2] libxl: do not assume Dom0 backend 
> > while listing disks and nics"):
> >> One more place where code assumed that all backends are in dom0. List
> >> devices in domain device/ tree, instead of backend/ of dom0.
> >> Additionally fix libxl_devid_to_device_{nic,disk} to fill backend_domid
> >> properly.
> > 
> > After this change, can a guest cause a backend to be leaked when the
> > domain is destroyed ?  If it deletes the contents of the frontend
> > directory in xenstore, I think the device will no longer show up in
> > the lists and so won't be deleted when the guest goes away.
> 
> Which is currently the problem for every non-dom0 backend, even without
> malicious domain action.
> Currently I've some python script which watch xenstore and remove leftover
> backends...
> 
> > Would iterating over all domains looking for backends for a particular
> > frontend domain work ?  That would allow a rogue guest to cause
> > entries to appear in the list of course, by pretending to be a
> > backend domain...
> 
> Perhaps frontend domain shouldn't have permissions to remove device directory,
> only modify some of entries, like state, feature-* etc. Does xenstore support
> something like:
> 1. allow creating new entries and modify some existing
> 2. disallow modify and/or remove some entries, in the same directory

I'm reasonably certain that in order to enable #1 you cannot have #2 (or
vice versa), since create/remove permissions is tied to the perms of the
containing directory. Or at least I think so, but I do know that XS
perms are a bit quirky. You could have a play with xenstore-chmod though
and see what you can see.

http://wiki.xen.org/wiki/XenBus#Permissions seems to be the best (AKA
only!) reference for the Xenbus permissions model I can find.

Ian.


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