[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xenstore domains and XS_RESTRICT



On 04/01/17 17:54, Ian Jackson wrote:
> Juergen Gross writes ("Re: Xenstore domains and XS_RESTRICT"):
>> Rejecting XS_RESTRICT for a non-socket connection is mandatory to
>> ensure a XS_RESTRICT user on an old kernel not knowing about it can't
>> drop the privilege of all other user's on that system, too.
> 
> Kernels need to proxy all commands from their users, so they should
> have a table (usually a switch statement) of supported commands.
> New commands are therefore unavailable until the kernel is updated.

Uuh, really?

I think this is true for only very few commands needing special
treatment (right now those are: start/stop transaction, register/
unregister watch). All other commands can just be passed through
without any need for special (command specific) treatment in the kernel.

XS_RESTRICT would be another command needing special treatment.

XS_DIRECTORY_PART introduced recently is a good example for a command
not needing any special kernel treatment. If the kernel would have a
positive list of commands to pass through this command would be
available on new kernels only limiting e.g. dom0 functionality
without any special need.

> I haven't checked the Linux xenbus chardev driver to see if it is
> correct ...

In your sense: no. For any non-special new Xenstore commands: yes.


Juergen

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.