On Sun, 12 Mar 2006 13:29:41 -0500, Daniel Veillard wrote:
>> 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
> ?
The cost of context switching is going to be negligible compared to the
cost of encrypting the traffic (not to mention the cost of byte code
translation within Xend).
> I have a hard time thinking it's a "great" solution. I probably misunderstood
> something.
It's really about where you do policy. Do you do it within Xend, or do
you do it outside of Xend. In this case, you would have Xend only
accessible to root, and then you have another application with suid
privileges that can implement a policy. Those roles are separate and well
defined.
Using ssh is kind of orthogonal to the above separation so you can think
about it independently. The advantage to using ssh as a transport is that
it totally punts the problem of authentication/authorization and privacy.
It's easy from an administrative point of view (no new ports need to be
opened up) plus it ties into enterprise-identity systems quite well.
>> 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.
Yup, let me be a bit more concrete.
Let's say we have xend and xend-remote. Xend is the daemon that listens
on a domain socket for XML-RPC. xend-remote is a command line tool that
is an XML-RPC proxy. It proxies stdio to a domain socket.
This tool can be setup to be SUID in which case it also reads a policy
file that in the simplest case, is a white list of which calls can be
executed by a particular user/group.
libvirt exec()'s a single instance of ssh with the -S option to set it up
to be in server mode. This is when authentication occurs.
Then, to execute individual XML-RPC calls, libvirt exec()'s ssh (again
with -S but this time as a client) which then uses the ssh running in
server mode as a proxy.
If you didn't want to go through the hassle of ssh, you could exec()
xend-remote directly (assuming you're only connecting to local host).
Then you don't need any authentication at all.
The alternative approach to this would be to have clients to Xend pass
SO_CRED stuff directly. Xend would then have to perform PAM
authentication (every time too since XML-RPC isn't stateful). If we
wanted privacy, we would have to implement server-side support for SSL.
There are advantages to this approach but I think it has the disadvantage
of making Xend more complex and having less flexible policy mechanisms.
For instance, using xend-remote, the XenSE guys could implement a much
more sophisticated proxy that was SSID-aware. If the standard policies we
provide didn't meet an admin's requirements, she could easily implement a
new xend-remote and everything would just work.
>> > 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 ?
Oh, I'm not familiar with SO_PEERCRED. A quick googling seems to suggest
it's Linux specific. The mechanism to authentication over domain sockets
that I'm aware of is SCM_CREDS which requires that the client actually
send the credential information (via sendmsg).
> 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.
I think I covered it above. If this is localhost management, virsh can
simply exec() xend-remote (once at library initialization) and use that as
a proxy SUID proxy to Xend.
Does this sound sane? This has been my long term vision for how
things ought to work. One could actually implement xend-remote pretty
easily right now. Of course, I'm flexible and open to alternatives.
Regards,
Anthony Liguori
>
> Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home