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
|
Home