[Libvir] PATCH: 1/10: SASL authentication support

Daniel P. Berrange berrange at redhat.com
Thu Nov 29 19:46:45 UTC 2007


On Thu, Nov 29, 2007 at 02:43:09PM -0500, Daniel Veillard wrote:
> On Thu, Nov 29, 2007 at 07:20:08PM +0000, Daniel P. Berrange wrote:
> > >    Actually there we should looks for a password and store it, that's very
> > > common and convenient, e.g. use
> > >    xen://foo:bar@server/
> > > 
> > > as the connection URI, libxml2 will just return the user as 'foo:bar'
> > > which could subsequently be split here to store the password (bar).
> > 
> > The virConnectCredentialPtr struct which is populated for the auth
> > callback function contains a 'defresult' field where the default value
> > of the credential should go. I intended to populate this value with the
> > username part of the URI for VIR_CRED_AUTHNAME credentials, but forgot.
> > Will add that in....
> > 
> > Using passwords in URIs is seriously frowned upon. URIs get into log files,
> > in the command line ARGV, into gconf, into bug reports. We absolutely do 
> > not want passwords visible in any of those places.
> > 
> > RFC 2396  explicitly recommends against using passwords in URIs
> > 
> >   "Some URL schemes use the format "user:password" in the userinfo
> >    field. This practice is NOT RECOMMENDED, because the passing of
> >    authentication information in clear text (such as URI) has proven to
> >    be a security risk in almost every case where it has been used."
> 
> 
> I know, I have also argued against it (and that's why libxml2 doesn't
> parse it), but this can be way more convenient at times, and also 
> has the potential to remove asynchronous interaction for example
> when using scripts.

There's better ways to deal with scripting. eg, we could add a flag to
virsh  '--auth /path/to/file'  where the file contained key,value pairs
for each credential. Or could have an env var VIR_AUTH_FILE pointing
to such a file, which can be processed by the default callback I aded.
That lets you automate login, without leaking the confidential data
anywhere.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 




More information about the libvir-list mailing list