[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH] docs: clarify xenstore permission documentation
In docs/misc/xenstore.txt the description of the Xenstore node access permissions is missing one important aspect, which can be found only in the code or in the wiki [1]: The first permission entry is defining the owner of the node via the domid, and the access rights for all domains NOT having a dedicated permission entry. Make that aspect clear in the official documentation. [1]: https://wiki.xenproject.org/wiki/XenBus#Permissions Signed-off-by: Juergen Gross <jgross@xxxxxxxx> --- docs/misc/xenstore.txt | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt index 8887e7df88..d807ef0709 100644 --- a/docs/misc/xenstore.txt +++ b/docs/misc/xenstore.txt @@ -45,13 +45,16 @@ them to within 2048 bytes. (See XENSTORE_*_PATH_MAX in xs_wire.h.) Each node has one or multiple permission entries. Permissions are granted by domain-id, the first permission entry of each node specifies -the owner of the node. Permissions of a node can be changed by the -owner of the node, the owner can only be modified by the control -domain (usually domain id 0). The owner always has the right to read -and write the node, while other permissions can be setup to allow -read and/or write access. When a domain is being removed from Xenstore -nodes owned by that domain will be removed together with all of those -nodes' children. +the owner of the node, who always has full access to the node (read and +write permission). The access rights of the first entry specify the +allowed access for all domains not having a dedicated permission entry +(the default is "n", removing access for all domains not explicitly +added via additional permission entries). Permissions of a node can be +changed by the owner of the node, the owner can only be modified by the +control domain (usually domain id 0). Other permissions can be setup to +allow read and/or write access for other domains. When a domain is +being removed from Xenstore nodes owned by that domain will be removed +together with all of those nodes' children. Communication with xenstore is via either sockets, or event channel -- 2.35.3
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |