[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 |