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).
> 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. Monitoring
should not require root priviledge IMHO, ps aux and top are not restricted
to root on Unix. And if you make Xen virtualization a sysadmin only feature
you restrain massively the area of usage IMHO, people will just use
something else (as stated QEmu requires no sysadmin priviledge, and if using
Xen can't be integrated seamlessly in the user workflow, they will switch to
something else).
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.
> 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
--
Daniel Veillard | Red Hat http://redhat.com/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home