WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [RFC] Xend XML-RPC Refactoring

On Sun, Mar 12, 2006 at 11:41:58AM -0600, Anthony Liguori wrote:
> On Sun, 12 Mar 2006 04:57:02 -0500, Daniel Veillard wrote:
> 
> > On Sat, Mar 11, 2006 at 10:20:53PM +0000, Ewan Mellor wrote:
> >> Of course, a full user / permissions system for the protocol would be a
> >> good idea, but like you say, it's not trivial work.  We could kick that
> >> discussion off if you want, but it's going to need someone to design
> >> the permissions semantics, management of users and roles, etc.  Is
> >> anyone interested in starting this?
> > 
> >   We need to make sure we can have authentication based on the transport
> > used, otherwise this need to be added at the RPC level (and hence changes
> > the API).
> 
> Here's my proposal:
> 
> We make a simple program that connects to a domain socket and funnels the
> stdin/stdout to that socket.
> 
> One can then build an XML-RPC transport on top of it via SSH.  The client
> side simply invokes ssh and treats it's stdio as it would a normal socket.
>  I've used this approach before with great success.

  You mean you're ready to force 4 context switches to make the RPC because
you don't want to handle authentication at the initialization of the protocol ?
I have a hard time thinking it's a "great" solution. I probably misunderstood
something.

> We get PAM authentication for free.  An advanced admin can suid that
> executable to delegate privileges.
> 
> I still think we ought to have a less privileged socket too but one that's
> remotable in a similar manner.
>  
> >> At the moment, the XML-RPC is over a Unix domain socket, so only root
> >> can use it anyway (as controlled by the permission on the socket file).
> > 
> >   To me that's a big regression. That mean libvirt can't be used anymore
> > to just monitor the Xen instance(s) without priviledged access.
> 
> The code is there for TCP.  It's just hard coded to use a domain socket
> right now.  When I make the change Ewan requested to allow it to be
> enabled/disabled I'll make it possible to choose the TCP version.

  yeah I think I'm lost.
I don't see how you could get to a good solution without separating the
various entry points based on different level of credentials.

> >   Well over (modern) unix socket one can extract the UID of the
> >   connecting
> > client, can we extract that from Python ? (c.f. LOCAL_CREDS/SO_PEERCRED)
> > If yes then that's a good first step toward local authentication without
> > messing with https and credentials.
> 
> Yeah, but that's a mess and requires specially constructed packets on the
> client side.  I think the ssh tunnel approach is a lot easier.

  For writing/running a client ? I'm lost, say I want virsh the shell
based on libvirt to list the running domains how do you get that working ?
virsh is a binary launched from an user shell and linked with libvirt 
what do you think should happen in this scenario ? Where is the ssh 
authentication handled ? when does it take place ? I'm lost. 

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

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