On Oct 25, 2007, at 1:47 AM, Magnus Hagander wrote:

On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
I know I haven't been very active for a while here, but I just got to
testing the October 3 version a bit prior to getting back to the Java
GSS client stuff I promised. There seem to be some funny things there.

Apologies for not responding to this one sooner.

BTW, what's the status on the Java stuff? Will it be around by the time 8.3
is released?

Touche.  ;-)  I hope to get to that in the next couple of weeks.

The only serious issue is that the server doesn't require the realm
name to match.  I haven't looked at how that broke yet, but I know I
was careful of that point in my original patches because it's always
been wrong in the Kerberos 5 auth method.

I honestly don't remember exactly how that became. I think I stripped it
out in order to make it work like the krb5 method.

What the krb5 method does is IMO a documented bug. The realm name is part of the name.

As I explained at some length you cannot assume the username (first component of the principal) has any meaning by itself, except in small deployments with no external trust agreements. Kerberos (and AD) are designed to support larger infrastructures with multiple organizations.

What you're asking for is basically a krb_match_realm parameter, or do I
understand you wrong?

I'm asking for name matching to be done i.a.w. the gssapi recommendations. That's "all" I want, but it's actually necessary for this feature to be at all usable in my environment. If we don't then I suggest we pull this feature until it can be done correctly.

If you want to add a non-default ignore_realm option I have no objection, but the code may not be robust to varying gssapi implementations. Guaranteed it won't work with a non-kerberos mechanism like SPKM (which isn't widely deployed).

For a proper discussion of this topic I recommend the section starting on page 64 of Sun's Security for Developers Guide, document 816-4863. Note that there is a discussion of how to do compares efficiently. IIRC my patch did things the "easy" way described on page 67. In the long run it's possible we'd want to do it the "fast" way described on page 69, but that's merely an optimization and might not be needed.

It appears that you can just put a complete (realm-included) name
into postgres, so that's obviously the way to support gssapi
connections from non-default realms.

In short this is a security hole.  IMO it should be fixed prior to

Can't you also configure the kerberos libraries on your machine not to
accept other realms than your own? IIRC, that was something considered at
the time, but I can't find a reference to such a discussion.

Kerberos is about authenticating (identifying) users, not determining what they're authorized (allowed) to do.

At the basic protocol level I can only refuse to exchange cross-realm keys with anybody. There's a NASA interpretation of a Presidential directive that would likely prohibit me from using this option, even if I wanted to. If I have even one user @NASA.GOV that I want to allow in to even one service @JPL.NASA.GOV then I can't use this option.

The three major Kerberos implementations, Microsoft, MIT (including Apple and Sun), and Heimdal, all have different degrees of support for authorization control.

MIT and Heimdal (and Microsoft, I assume) will let you trust STANFORD.EDU and *.NASA.GOV without (for example) trusting STANFORD.EDU to identify [EMAIL PROTECTED]

Microsoft bundles their Kerberos with an LDAP server so they can do fine-grained authorization control from the same place. Every individual user in any trusted realm needs to have an entry in the local LDAP in order to get access to a Windows service.

MIT supports an "auth_to_local" translation service to relate Kerberos principals to local workstation usernames. By default, the local realm is translated to the username by stripping the realm name. Other realms do not translate. The facility is poorly documented, and not standard, so I cannot recommend it.


I notice there are hba options for gss and sspi both.  Why?

Is there some windows-only functionality it enables?  Shouldn't we be
using Microsoft's advertised GSSAPI/SSPI compatibility?  If you build
on Windows then I'm sure you want to link the SSPI libraries rather
than require installation of a separate package, but that shouldn't
change the functionality or the wire protocol AFAIK.  In other words
I would expect this to be a build-time option.

There was discussion about this, and we were presented with clear cases
where you'd want to be able to do either one. Making it a build option
doesn't help the 99.9% of Windows users that use a pre-packaged binary

Doesn't exactly answer my question, but I guess there exists a Windows use case where linking against a non-SSPI support library is needed. (I actually have such a use case, but I'd consider it a transient problem due to a bad deployment.) This puts you into the deployment model that Firefox uses, where there's a config option for which support library you use. Sounds messy, and I feel sorry for the people who have to support it.


At the risk of diluting my message:  I still think it's a mistake to
call it gss instead of something like gss-noprot.  I believe this
will cause misunderstandings in the future when we get the security
layer of gssapi implemented.

Well, I don't agree with this, but if others want it changed, it can
certainly be changed. And it can only be changed *now*, and not once we

But we have "host" and "hostssl", not "hostnossl" and "host". So the way we are donig it now is IMO more consistent with what we have in other parts of pg.

Sorry, I don't follow how that's comparable, unless you're proposing a "hostgss" option for the future? We can agree to disagree on this point, but. . .

GSSAPI includes session encryption. I couldn't figure out how to fit that into PG's buffering model, so I supplied a stripped down patch that omitted that capability. (After all the current krb5 method omitted the capability as well.) I don't think we should pretend that what we're delivering now is the full, standard capability. It's not best practice.

I hope I don't sound like I'm whining here. I do appreciate the support you've given me. I still want to deliver what I promised. I'm sorry that that JPL project decided to go with MySQL instead, but that affects the priority I can give this work.

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