From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Veillard Subject: Re: Re: [RFC] Xend XML-RPC Refactoring Date: Sun, 12 Mar 2006 13:29:41 -0500 Message-ID: <20060312182940.GG22089@redhat.com> References: <440E204B.1070402@us.ibm.com> <20060311205510.GH13877@leeni.uk.xensource.com> <20060311213657.GM346@redhat.com> <20060311222053.GA5963@leeni.uk.xensource.com> <20060312095701.GC22089@redhat.com> Reply-To: veillard@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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/