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.
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.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
---------------------------(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
match
