* Re: domU reading its own xenstore home directory from userspace
2005-12-02 20:45 domU reading its own xenstore home directory from userspace Andrew D. Ball
2005-12-02 23:07 ` Anthony Liguori
@ 2005-12-05 13:06 ` Ewan Mellor
2006-01-16 16:34 ` Charles Duffy
1 sibling, 1 reply; 4+ messages in thread
From: Ewan Mellor @ 2005-12-05 13:06 UTC (permalink / raw)
To: Andrew D. Ball; +Cc: xen-devel
On Fri, Dec 02, 2005 at 03:45:11PM -0500, Andrew D. Ball wrote:
> What does this statement in the xenbus documentation on the xen wiki
> mean: "The DomU kernel interface is structured in such a way that nodes
> in the "home directory" of the domain cannot be addressed, and therefore
> cannot be read from or written to. Tools may use this space to store
> data that should not be accessed by the domain itself." ?
> [ from http://wiki.xensource.com/xenwiki/XenBus , toward the bottom ]
>
> I thought domU kernels must read data in the domU's home directory or is
> the data that drivers watch somewhere else?
>
> I want to read this data from domU userspace that that a domU can find
> out what it's UUID is. This is important for correlating domU's with
> the dom0's they run on for management tools. Reading a UUID from a
> domU's xenstore home directory from domU userspace is the cleanest way
> to do this that I can think of at the moment.
The permissions checking in Xenstore have recently been re-enabled, so I shall
explain. The text on the wiki is wrong in any case.
Any guest can read any part of the store, but _only_ if it has permission to
do so. Domain 0 may read or write anywhere in the store, regardless of
permissions, and permissions are set up by the tools in domain 0, or by
Xenstored when it first starts up.
The store structure looks like this:
/tool/xenstored xenstored-specific storage
/tool/... available for other tools
/vm/<uuid>/name VM name
/uuid VM UUID
... other VM-specific details
/local/domain/<domid>/vm Path to this domain's VM store entries
/... other domain-specific details
In domain 0's section, you would expect to see
/local/domain/0/backend/<deviceClass>/<frontendID>/<deviceID>/...
Whereas for an unprivileged guest you would expect
/local/domain/<domID>/device/<deviceClass>/<deviceID>/...
These two directories are for the backend and frontend drivers for each
device, respectively.
It is up to Xend (or other tools) to set up the permissions on the appropriate
sections on the store. It sets /vm to be readable only by domain 0,
/local/domain/<domid> to be read-write by the guest, and
/local/domain/0/backend/XYZ to be read-write by dom 0, read-only by the guest,
for each of the guest's devices.
Note that this means that to do what you want (read the UUID from the /vm
path) will require a change to Xend to make that node readable by the guest.
The permission semantics for Xenstore are a bit strange, so I shall explain
those too.
There is are calls in the Python layer -- xstransact.SetPermissions and
xstransact.set_permissions -- and a corresponding C layer call --
xs_set_permissions -- each of which takes a path, and a list of (domid,
permissions) pairs. I shall use the Python syntax, as this is clearer. In
this case, read and write flags are specified, which are packed into the
"permissions" field in the tuple.
xstransact.SetPermissions(path, { 'dom' : dom1,
'read' : True,
'write' : False },
{ 'dom' : dom2,
'read' : True,
'write' : True },
{ 'dom' : dom3,
'read' : True,
'write' : True })
This looks clear, but actually the semantics of this are strange. The first
element in this list specifies the owner of the path, plus the read and write
access flags _for_every_domain_unspecified_subsequently_. The owner _always_
has read and write access to their nodes. The subsequent entries are normal
capabilities. The example above, therefore, sets the permissions on the path
to be such that domain 0 (being privileged), dom1 (being the owner), and
domains dom2 and dom3 (being explicitly specified) can _all_ write to the
node. Any other domain can only read, as specified by the first pair of
'read' and 'write' flags.
Finally, please note that permissions in the store are inherited from parent
to child, but _only_ when the child is created. This means that if you do
write('/tool/mytool/foo', 'Hi')
write('/tool/mytool/bar', 'Hello')
set_perms('/tool/mytool', { 'dom' : 0,
'read' : True,
'write' : True })
then foo and bar will not necessarily be read/write everybody! They will
instead have the permissions of /tool/mytool at the time of the writes, so if
/tool/mytool did not exist at the time, then foo and bar will be unreadable by
anyone except dom0 and the domain that created them.
Xend is careful to do
rm('/local/domain/<domid>')
mkdir('/local/domain/<domid>')
set_perms('/local/domain/<domid>', { 'dom' : <domid> })
for this very reason.
HTH,
Ewan.
^ permalink raw reply [flat|nested] 4+ messages in thread