Re: Preliminary GSSAPI Patches - Mailing list pgsql-patches
From | Henry B. Hotz |
---|---|
Subject | Re: Preliminary GSSAPI Patches |
Date | |
Msg-id | D54C66F1-E2F0-478A-8F08-126D8E0D159E@oxy.edu Whole thread Raw |
In response to | Re: Preliminary GSSAPI Patches (Magnus Hagander <magnus@hagander.net>) |
Responses |
Re: Preliminary GSSAPI Patches
|
List | pgsql-patches |
On Jun 22, 2007, at 9:56 AM, Magnus Hagander wrote: > Stephen Frost wrote: >> * Magnus Hagander (magnus@hagander.net) wrote: >>> We enable the setting of the service name in the server >>> configuration >>> file, but we never use that variable anywhere. We do, however, >>> use the >>> service name on the client, in order to pick the correct key (and >>> turning this off makes GSSAPI no longer work). >>> >>> If this is correct, we should not enable that parameter on the >>> server. >>> If it's not correct, we should be using it somewhere. >> >> Uh, shouldn't you be acquiring the server credentials before >> accepting >> the context? That'd be done using gss_acquire_cred(), which takes >> the >> service name (in gss_name_t structure) as an argument. That would >> then >> be passed in to gss_accept_sec_context() instead of using >> GSS_C_NO_CREDENTIAL (in port->gss->cred). > > That's the direction I was thinking in. I just wanted to have it > confirmed. Henry, what's your take on this? > >> I'm kind of suprised it's >> working without that and rather curious as to what it's doing >> under the >> hood to make that happen. :/ > > Most likely it's just checking the keytab to find a principal with the > same name as the one presented from the client. Since one is > present, it > loads it up automatically, and verifies against it. Bingo! 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. The real question is whether we *need* to check anything. If the keytab is unique to PostgreSQL, as I think it should be, then I think the admin should put only the right stuff in the keytab, and no further checks are needed. Now it *might* make sense to check that the credential that's accepted actually has some correspondence to what ./configure said. If we do do that, then we need to allow for the ways Microsoft mucks with the case of the name. (Kerberos is supposed to be case sensitive, but Microsoft work that way.) In particular I think we may need both postgres/<server> and POSTGRES/<server> in the keytab in order to support the to-be-written native Windows SSPI client at the same time as the current Kerberos 5 and GSSAPI Unix clients. Now what happens with non-Kerberos 5 mechansims like SPKM and SPNEGO? ;-) I'll have to see, even if it doesn't matter for Java, yet. ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
pgsql-patches by date: