|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xenstore domains and XS_RESTRICT
Juergen Gross writes ("Xenstore domains and XS_RESTRICT"):
> In order to solve the problem I suggest the following change to the
> Xenstore wire protocol:
>
> struct xsd_sockmsg
> {
> - uint32_t type; /* XS_??? */
> + uint16_t type; /* XS_??? */
> + uint16_t domid; /* Use privileges of this domain */
I don't think this is a particularly nice extension. (Also the way
you have written it has an endianness hazard.) What if we decide, at
some future point, to support domids >2^16 ? That's hard right now
but I don't want to make it harder.
I suggest the following protocol extension instead:
Add to xenstore.txt (the list of xenstore commands):
RESTRICTCMD <domid|><realcommand|><realpayload|>
Here <domid|> is a domain id, and <realcommand|> is a command
number; both of these are 32-bit integers in host byte order.
This is an instruction to execute the command <realcommand|>
with payload <realpayload|>. However, all permissions
checking should be done as if the command had been issued by
domain <domid|>.
The req_id and tx_id, and (if the command affects watches) any
watches that are manipulated, are those of the calling
connection. So the reply is sent to the xenstore client
(usually, ring client) which sent the RESTRICTCMD command.
If RESTRICTCMD is used to invoke WATCH, the <domid|> from the
RESTRICTCMD is attached to the watch, in xenstored. Insofar
as watch events are filtered by the permission system, the
<domid|> from the RESTRICTCMD is used for watch events
originating from such a watch. But the actual watch events
are sent to the connection that called RESTRICTCMD.
This is similar in semantics to RESTRICT but applies to this
one particular command (and its effects), only.
RESTRICTCMD has no effect on, and is not visible through, the
xenstore ring connection of domain <domid|> (if that domain
has one).
What do you think ?
There is a command length limit implication but I don't think that's
important.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |