[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [RFC] Xend XML-RPC Refactoring
Ewan Mellor wrote:
On Sat, Mar 11, 2006 at 04:36:57PM -0500, Daniel Veillard wrote:
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?
We can do basic authentication and require root credentials as a start.
That's really easy to do but I'm not sure sending the root password as
clear text really makes things much better :-)
Python, unfortunately, doesn't have server-side SSL bindings so basic
authentication over SSL is not an option without some custom OpenSSL
bindings.
Regards,
Anthony Liguori
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
|
