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

Re: [Xen-API] Use of PAM for authentication & SSL comms

To: Alastair Tse <atse@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] Use of PAM for authentication & SSL comms
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Wed, 1 Nov 2006 11:57:27 +0000
Cc: xen-api@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 02 Nov 2006 13:58:39 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <2216ED7D-1DFA-48C6-A794-FC6166CE5AF2@xxxxxxxxxxxxx>
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>
References: <20061031232952.GB30970@xxxxxxxxxx> <2216ED7D-1DFA-48C6-A794-FC6166CE5AF2@xxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Wed, Nov 01, 2006 at 11:38:47AM +0000, Alastair Tse wrote:

> > - XenD should install its own PAM config file into /etc/pam.d
> >   rather than re-using the context from the 'login' program
> 
> 
> Well, the problem I ran into is that every distro has their own  
> custom PAM stack and any PAM stack we write will only work on one  
> distro and not another. I believe this is a distro packaging problem.  
> But your concern is still valid, maybe we have to provide a PAM stack  
> for one at least one distro. Let's fight to see which one that will  
> be :)

Back off, Gentoo-freak ;-)

> > - If we're using PAM then we must switch all communications to use
> >   SSL by default - no network daemon should be using system
> >   passwords over a cleartext network channel anymore. If we want
> >   to keep a cleartext channel, then we should use a separate
> >   password database & certainly not system logins
> 
> Definitely. I've only been testing with a local UNIX domain socket.  
> Anything that goes over the network needs SSL encryption, but the API  
> docs don't make any mention of this, presumably because it doesn't  
> really fall into the API.

Actually, I agreed at the last Xen Summit that we would add a list of
supported transports to that API document.  The intention is that any server
meeting the spec can talk to any client meeting the spec, so of course we need
a list of supported transports too.

This list is something we need to write down -- HTTP/local, HTTP/TCP,
HTTP/SSL/TCP are the obvious ones, but if someone needs something else, it's
still open to discussion.

> My guess is we'll need to put some  
> certificate configuration options in xend-config.sxp or run the Xen  
> API on a different XMLRPC server than the one that currently serves xm.

Yeah, I think that we're certainly going to need to use a different port, even
if we're using the same dispatcher behind that.  I'm not sure what to do about
certificate management -- any suggestions?

Ewan.

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