On Sat, Mar 11, 2006 at 04:36:57PM -0500, Daniel Veillard wrote:
> > It would be prudent to make it possible to turn the XMLRPCServer off, just
> > as we
> > can turn the other servers off.
>
> Big dilemna :-)
> Currently with http on anybody can manipulate any Xen instance as soon
> as one has Xen0 access (I run my libvirt regression test from my normal
> user login but except for the convenience it's a bit scary :-). I assume
> It will be exactly the same with XML-RPC. I would feel way better if we
> could have a policy model which is not all on or all off implemented,
> for example associating users with domains, and controlling per user
> resource usage. I know that the obvious answer would be "only root should
> do that" except that a frustated user needing his VM could then launch
> a qemu instance instead and that wouldn't be any better for the server.
> IMHO a smarter, more fine grained approach is needed, it will also require
> authentication at connection time to the service, and even if not trivial
> this should be doable and we use authenticated XML-RPC call all the time
> for the Red Hat Network framework, so this has to be possible locally and
> remotely.
Turning the server on and off is just for basic sanity -- the admin gets
to choose which ports they want open so that they don't have to audit
aspects in which they aren't interested.
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?
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).
> > > diff -r c369d960f96b -r 095ac0d95d9c tools/python/xen/util/xmlrpclib2.py
> > > --- /dev/null Tue Feb 28 16:45:20 2006
> > > +++ b/tools/python/xen/util/xmlrpclib2.py Tue Feb 28 22:08:47 2006
> > >
> > > [Snip lots]
> > >
> > > +class ServerProxy(xmlrpclib.ServerProxy):
> > > + def __init__(self, uri, transport=None, encoding=None, verbose=0,
> > > + allow_none=1):
> > > + if transport == None:
> > > + protocol = uri.split(':')[0]
> > > + if protocol == 'httpu':
> > > + uri = 'http:' + ':'.join(uri.split(':')[1:])
> > > + transport = UnixTransport()
> >
> > How about
> >
> > (protocol, rest) = uri.split(':', 1)
> > if protocol == 'httpu':
> > uri = 'http:' + rest
> > transport = UnixTransport()
>
> hum, do we really need to invent a new transport for local access ?
> I don't remember seeing 'httpu' anywhere, sounds weird to me
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).
> [...]
> > > except SystemExit:
> > > + sys.exit(1)
> > > + except xmlrpclib.Fault, ex:
> > > +# print "Xend generated an internal fault:"
> > > +# sys.stderr.write(ex.faultString)
> > > +# sys.exit(1)
> > > + print "Error: Internal Xend error"
> >
> > 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)?
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home