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

[Marek Marczykowski <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1464 bytes --]

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
?

-- 
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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