WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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