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

[Daniel Veillard <veillard@redhat.com>]

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@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/