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

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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.

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.

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

Regards,

Anthony Liguori

>> httpu is HTTP over a unix domain socket, as opposed to over TCP.  It's
>> used elsewhere (though not widely, obviously).  It gives you basic
>> protection from non-root users (see your complaint above).
> 
>   It's not a complaint, I'm raising a problem, which IMHO is different.
> Adding core piece of OS machinery without thinking of security and
> authentication aspects from the start is a mistake that had been done on
> Unix already, it would be great to not go though the mess again just
> because we are eager to push a solution, the subsequent costs could
> reduce the benefits from the effort getting there ;-)
> 
>> > > I expect we can do better than just printing "Internal Xend Error".
>> > >  How much structure and useful information is there in an
>> > > xmlrpclib.Fault at the moment?
>> > 
>> >   Another good question, as we are defining an API to Xend I think
>> > the error handling question will become more and more important. The
>> > client will need more structure and informations about processing
>> > error, the full stack trace within xend might not be that useful
>> > (except for low level debugging) to the clients, but currently I just
>> > extract a string like
>> >   "No such domain test"
>> > which is a bit hard to process correctly even in context. A list of
>> > predefined error code and meaning could help quite a bit along with
>> > just the error message.
>> 
>> Sure.  Do you have a list of error codes already (for libvirt, for
>> example)?
> 
>   Yes but for the moment they can't capture what's happening within
>   Xend,
> so if the RPC fails they show up just as being from within Xend, with
> either a GET or POST information and the string found in the content of
> the HTTP answer:
>     http://libvirt.org/html/libvirt-virterror.html#virErrorNumber
>  associated docs:
>     http://libvirt.org/errors.html
> 
> Daniel



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