On Jun 22, 2007, at 9:56 AM, Magnus Hagander wrote:

Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) 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.


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.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to