WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

[Xen-API] Use of PAM

To: xen-api@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-API] Use of PAM
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
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

<Prev in Thread] Current Thread [Next in Thread>