Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Juergen Gross <jgross@xxxxxxxx>]

On 07/12/16 18:10, Ian Jackson wrote:
> 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.

Do we support any big endian systems? I don't think so. An endianess
problem could occur only if there are any big endian systems using the
old (current) struct xsd_sockmsg.

Regarding size of domid: this is true.

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

Hmm, normally parameters outside the command header are transferred
using ASCII representation. Do we really want to introduce the first
exception?

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

That was the first problem coming to my mind. OTOH I'm not sure this
is really a problem as users of RESTRICTCMD should have no need to
use payloads of 4k.

In summary I see advantages for both solutions. IMO the needed changes
for my solution will be a little bit smaller, though.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel