Re: krb_match_realm - Mailing list pgsql-patches

On Fri, Nov 02, 2007 at 11:23:30AM -0700, Henry B. Hotz wrote:
> >>>>I'm not entirely sure what the intended semantics of
> >>>>krb_match_realm
> >>>>are, but if you're trying to match the GSSAPI-authenticated name
> >>>>against
> >>>>"value_of(PGUSER)@value_of(krb_match_realm)" then you need to
> >>>>construct
> >>>>that string, gss_import_name() it, and then gss_compare_name() the
> >>>>imported name with the authenticated name that GSSAPI already
> >>>>gave you.
> >>>>I know the API overhead of doing that is a PITA, but that's
> >>>>what's going
> >>>>to work.
> >>>
> >>>Why?
> >>
> >>Because if we're using the GSSAPI then we need to use the properties
> >>defined by the GSSAPI, and not depend on observed behavior of
> >>specific
> >>implementations of specific mechanisms.  Otherwise things will be
> >>non-portable or unreliable in ways that may be non-obvious.
> >>
> >>In particular gss_display_name() produces a character string intended
> >>for display to a human being.  It is *NOT* intended for access
> >>control.
> >>As another example, Heimdal gss_display_name() puts '\' escapes in
> >>front
> >>of special characters in the username.  I don't think it's worth
> >>writing
> >>special case code for that either.
> >
> >Ok. I can see that point. However, if you have those characters in
> >your
> >username, you may have other problems as well :-)
>
> Yeah.  Not many people put spaces inside usernames.

I think we can easily get away with not covering that case.


> >Is there some other way to actually get the username from gss? I mean,
> >if we *didn't* get it from the startup packet, how would we ever be
> >able
> >to determine what user logged in?
>
> gss_export_name(), but what it returns is supposed to be an opaque
> binary blob.
>
> It's guaranteed to produce a unique, canonicalized name based on the
> specific mechanism in use.  It is suitable for memcmp().  The
> exported name will re-import.  Section 3.10 of rfc 2744 describes all
> this, and appears to be clearer than the Sun document I pointed you
> at.  Certainly it's more concise.  YMMV.

Hmm. But it doesn't serve our purpose.


> memcmp() on exported names will only be true if everyone uses the
> same gss mechanism.  (OK, the only one we care about is kerberos.)
> In contrast it's possible that gss_compare_name() would say that
> "uid=smith,ou=People,dc=example,dc=com" is the same as
> smith@EXAMPLE.COM.

No, memcmp()ing two separate strings (userid + match realm) with an opaque
binary blob certainly won't help us at all.


> >>The standard defines two ways to do comparisons for access
> >>control.  We
> >>should use one of them.  Anything else is going to be more work
> >>and less
> >>reliable.
> >
> >What's the other way then?
> >
> >Last I checked there was no way to do case insensitive matching on
> >gss_compare_name() but I could be on the wrong docs? Finding any
> >kind of
> >consistent docs for this stuff isn't exactly easy.
> >Because we *must* have the ability to do case insensitive matching, or
> >it *will* break on Windows.
>
> No gss_compare_name() is case sensitive.  I think the way to do it is
> to know what case Microsoft is going to use and pre-map everything to
> that case (before you do a gss_import_name()).  I *think* Microsoft
> will use upper case for the service name so we will need to change
> from "postgres" to "POSTGRES" as the default name in service
> principals.  I've seen places where they may be using lower case
> realm names (which makes *NO* sense to me).

No. Microsoft will send you whatever case the user put into the login box
when he logged into windows. It's case-*preserving*, but case-insensitive.

However, AD itself requires uppercase service name, but that's a different
thing.

> Absent an environment where I can actually look at all these things,
> my only point of reference is mod_auth_kerb, and the issues reported
> with it.  I know an upper case "HTTP" is needed to interoperate with
> windows clients.  An upper case realm name seems to be OK, as is a
> lower case server name in the second component.  The actual usernames
> seem to be lower case, but that's not the concern of the
> mod_auth_kerb developers since the deployer just needs to put in
> whatever matches.

The usernames depend on what the client puts in. It's generally a big
problem because a lot of krb-aware applications can't deal with it.

> I assume in AD you can't create both "smith" and "Smith", but can you
> create the latter at all?  If you do, does AD remember the case for
> display purposes?  Here at JPL usernames are lower case, and I don't
> think we allow anything special but hyphens in them, so I'm not
> likely to see a lot of the possible corner cases.

You can and it remembers. But it has no effect on what is sent ni the
kerberos packets - what's sent there is what the user typed in. Yes, that
sucks bad, but that's how it is.

> I think you can upper case the service name, lower case the server
> name, upper case the realm name, and lower case the user name.  If
> you can create "Smith" in AD and the user gets authenticated as
> "Smith@EXAMPLE.COM" at the protocol level then that won't work though.

Which is how it is :-(



From what I can tell, the least bad way to do it is still the patch that
sits in the queue now (pending changes based on Stephens comments, but
those are a differnt thing)

//Magnus