Re: [Xen-devel] [PATCH] libxl: Use xenbus to communicate with xenstore if the socket fails

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Thu, 2010-12-09 at 09:59 +0000, Mihir Nanavati wrote:
> Sure, that sounds doable. 
> 
> I'm not sure what the behaviour of the readonly should be though - I
> don't see any way of opening the xenbus client as readonly, or at
> least nothing quite as simple as a xs_domain_open_readonly.

What are readonly connections actually used for? Are they actually
enforcing some part of the security model or just preventing casual
accidents?

The only user I can see is libxenstat which immediately beforehand
opened the privcmd interface so it's already privileged enough to get a
rw connection if it wants. The python bindings provide the functionality
but I can't see it being used anywhere.

Perhaps just open /proc/xen/xenbus with O_RDONLY and if the kernel
driver doesn't enforce that then it's a bug in the driver, but not a
critical one since we don't actually rely on it for security?

>  How should a xs_open(1) behave in the case that
> xs_daemon_open_readonly fails? A null or a xs_handle using
> xs_domain_open?

I don't think there is any harm in trying to open the rw handle -- if
that succeeds then the calling process is privileged enough in the first
place.

> Is there a way to constrain the xenbus handle using some other
> mechanism?
> 
> ~M
> 
> On Thu, Dec 9, 2010 at 1:17 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> wrote:
>         On Wed, 2010-12-08 at 20:47 +0000, Mihir Nanavati wrote:
>         > Adds an open xenstore connection function which tries to use
>         the
>         > xenbus interface (xs_domain_open) when the socket interface
>         > (xs_daemon_opn) fails.
>         
>         
>         I like the concept of this patch.
>         
>         I can't think of any reason why the callers of libxenstore
>         should need
>         to care about how which communication channel gets used so
>         there's no
>         reason for the library to defer that choice to the caller. So
>         perhaps we
>         should go one step further push this behaviour down into
>         libxenstore
>         itself? i.e. add "xs_open(int ro)" and make
>         xs_{daemon,domain}_open{,_readonly} compatibility aliases to
>         that
>         function.
>         
>         
>         > Signed-off-by: Mihir Nanavati <mihirn@xxxxxxxxx>
>         
>         
>         
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel