From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC] Xend XML-RPC Refactoring Date: Sat, 11 Mar 2006 19:46:35 -0600 Message-ID: <44137D7B.7050403@us.ibm.com> References: <440E204B.1070402@us.ibm.com> <20060311205510.GH13877@leeni.uk.xensource.com> <20060311213657.GM346@redhat.com> <20060311222053.GA5963@leeni.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060311222053.GA5963@leeni.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ewan Mellor Cc: Ian Pratt , xen-devel@lists.xensource.com, Daniel Veillard List-Id: xen-devel@lists.xenproject.org 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. >