Hi, I encountered a problem while testing non-dom0 backend driver. I''m using 3.0.3-0. I create backend and frontend vbd devices as below: frontend path - /local/domain/4/device/vbd/1 backend path - /local/domain/3/backend/vbd/4/1 When I try to destroy dom 4 (frontend dom), the frontend path is removed in a transaction. In the end of that transaction, xenstored will try to fire watches for what has been removed. Since backend is watching /local/domain/4/device/vbd/1/state, the watch should be fired for it, which is exactly the case for a dom0 backend device. But, for a domU backend device (which is my case), the watch is not fired. The reason is that the permission of frontend path for dom 3 (backend dom) is already gone during the transaction. So, xenstored will check the parent directory (/local/domain/4/device/vbd) to determine if dom 3 has the permission to know that the frontend path is gone. Unfortunately, although backend has the read right for /local/domain/4/device/vbd/1 and set watch on /local/domain/4/device/vbd/1/state successfully, it has *no* read permission for the parent directory (/local/domain/4/device/vbd), which cause the watch-firing to fail. (As for a dom0 backend device, it has all permissions automatically, so the watch will be fired for a dom0 backend device driver correctly.) Is it a bug that a domU has no read permission to a path while has read permission to a path under it? Thanks, Max _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2006-Nov-01 11:03 UTC
Re: [Xen-devel] problem of the permissions system in xenstore
On 1/11/06 10:32, "Max Zhen" <Max.Zhen@Sun.COM> wrote:> Is it a bug that a domU has no read permission to a path while has read > permission to a path under it?No that is valid, but the xenstored code is also quite anal about letting untrusted clients know about presence/absence of nodes in subtrees for which it has no access permissions. This case is obviously a bug -- a watch should fire when a watched node disappears, even if the watcher cannot tell the difference between that and the node being inaccessible. I presume you have already tracked this down in xenstored. Can you make a patch? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel