[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-API] Use of PAM


  • To: xen-api@xxxxxxxxxxxxxxxxxxx
  • From: John Levon <john.levon@xxxxxxx>
  • Date: Mon, 5 Feb 2007 02:28:54 +0000
  • Delivery-date: Sun, 04 Feb 2007 18:20:01 -0800
  • List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>

First off, I've never looked at PAM, and I probably have totally the wrong end
of the stick.

The API authorization uses the PAM 'login' stack. If I'm understanding things
right, this means that any user/pass pair that matches /etc/passwd etc. will be
able to log in. This seems really odd to me - why are matching up "can start a
session in xend api" with "has a login account under the name services"? Given
this doesn't provide meaningful authentication, what is the session intended
for?  Shouldn't we be using a new service name along with a pam_xendauth module
or similar?

Of course there's no security layer above the XMLRPC defined either. AIUI
you're still restricted to being root on the local machine or providing
separate authorization over https.

Imagine I wanted to delegate xend xml-rpc management to a local user on the
machine (ignoring for now fine-grained control). I can't let normal users have
permissions on the socket, since they can just get a session with their normal
user/pass; I'd have to make them root.

Is this what

"\item Delegation to the transport layer.
\item Extend PAM exchange across the wire.

is referring to in the TODO? Are there concrete plans on how this would work?

Is the session ID really cryptographically secure? The uuidgen man page worries
me. Couldn't/shouldn't this creation of a session ID be delegated to a PAM
module too?

Finally, are there plans for fine-grained access control + delegation ("let foo
control this domain"), and will it be PAM-based too?

I suppose I'm confused on what the plans are for authentication, delegation and
auditing in both the local-user and the remote-user cases.

thanks,
john

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.