[Xen-devel] xenstore backend cleanup issue with driver domains

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

Hi,

I've found an issue with backend xenstore entries cleanup when driver
domains are in use. I've found it on vif devices (and will use them as
examples) but I believe the issue is generic.
When device is removed, backend domain (driver domain or not) is
responsible for removing entries in /local/domain/.../backend/ tree.
Specifically, it's done in libxl__device_destroy ->
libxl__xs_path_cleanup. The issue is that driver domain don't have
necessary access for this:

backend/vif/36 = ""   (n0,r1)
backend/vif/46 = ""   (n0,r1)
backend/vif/46/0 = ""   (n1,r46)
backend/vif/46/0/frontend = "/local/domain/46/device/vif/0"   (n1,r46)
backend/vif/46/0/frontend-id = "46"   (n1,r46)
backend/vif/46/0/online = "1"   (n1,r46)
backend/vif/46/0/state = "4"   (n1,r46)

As you can see, backend domain (1) has access only to a specific device
node, but not to the parent directory. This leads to a lot of empty
directories left behind, to the point xenstore list fails with E2BIG (if
you create and destroy a lot of domains).

I see two solutions for this:
 - adjust xenstore permissions, so the driver domain can properly
   cleanup those entries
 - cleanup it from dom0

I think the first one is better, especially when libxl keeps its view of
the things in /libxl (so there is less risk of malicious driver domain
confusing libxl). The second one don't require any permission change,
but may be racy if both dom0 and driver domain try to cleanup things.

Any insights?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel