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
|
Home