WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] problem of the permissions system in xenstore

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] problem of the permissions system in xenstore
From: Max Zhen <Max.Zhen@xxxxxxx>
Date: Wed, 01 Nov 2006 18:32:30 +0800
Delivery-date: Thu, 02 Nov 2006 13:38:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.5 (Windows/20060719)
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>