Skip site navigation (1) Skip section navigation (2)

Re: Preliminary GSSAPI Patches

From: "Magnus Hagander" <magnus(at)hagander(dot)net>
To: hbhotz(at)oxy(dot)edu
Cc: sfrost(at)snowman(dot)net, pgsql-patches(at)postgresql(dot)org
Subject: Re: Preliminary GSSAPI Patches
Date: 2007-06-25 06:03:53
Message-ID: 20070625060358.CC03CDCCAF1@svr2.hagander.net (view raw or flat)
Thread:
Lists: pgsql-patches
> >>> The server uses the keytab to decrypt the token provided by the
> >>> client.  By using the GSS_C_NO_CREDENTIAL arg on the server anything
> >>> put in the keytab is OK.  (The server doesn't need to authenticate
> >>> itself to Kerberos, it just accepts authentication.  Mutual
> >>> authentication is done using the same keys.)  The documentation  
> >>> needs
> >>> to reflect that.
> >>
> >> I agree there's some disconnect there between the documentation  
> >> and the
> >> apparent implementation but I'm not sure I'm in favor of changing the
> >> documentation on this one.  Personally, I'd rather it return an  
> >> error if
> >> someone tries to use GSS_C_NO_CREDENTIAL when accepting a context  
> >> than
> >> to just be happy using anything in the keytab.
> >
> > How about doing both, then? Set the principal name if it's  
> > specified in
> > the config file. If it's explicitly set to an empty string, use
> > GSS_C_NO_CREDENTIAL. Seems straightforward enough to me, and shouldn't
> > be hard to implement.
> 
> I don't have a problem with that, but you'll want multiple service  
> names as soon as you want to support the SSPI.
> 
> Also don't get too bent out of shape about some client using the  
> wrong service name.  The client *still* needs to prove who it  
> represents;  there's no hole there.  The only real security issue I  
> can think of is that someone who subverts the PostgreSQL server could  
> steal the "host" service keys and then (with a whole bunch of other  
> work) masquerade as the SSH daemon.

Ok. that's certainly a lot more narrow than I thought. you can see from my updated patch that it's not particularly lots of code. but if the gain is so little 
and we end up recommending people not to use that part anyway for compatibility I'm more than happy to take it out again. You certainly know more about these 
aspect of gss than me ;)

> Don't read too much into the mod_auth_kerb situation.  The main  
> reason it still takes a specific, configured service name is that  
> neither Russ Allbery nor I has gotten around to submitting a proper  
> patch to fix that.  The only reason it was written the way it is in  
> the first place is that the ability to use GSS_C_NO_CREDENTIAL that  
> way is "obscure" and most people don't know it.  I can say that with  
> some confidence because Russ and I had a long discussion with Sam  
> Hartman about how it ought to be done.

Ok. That makes a lot of sense then.

> I'm told that the way Apple's equivalent to mod_auth_kerb works is it  
> uses GSS_C_NO_CREDENTIAL and then does a case-insensitive compare of  
> the resulting match to "HTTP".  We could do the same thing, if you  
> think it's worth it.

Do you know if this is documented somewhere? It's always nice with references.

/Magnus


In response to

Responses

pgsql-patches by date

Next:From: Michael PaesoldDate: 2007-06-25 06:07:26
Subject: Re: msvc and vista fun
Previous:From: Greg SmithDate: 2007-06-25 05:50:58
Subject: Re: Load Distributed Checkpoints, take 3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group