Re: krb_match_realm

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>
Cc: "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: krb_match_realm
Date: 2007-11-06 14:27:07
Message-ID: 20071106142707.GI32607@svr2.hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)EXAMPLE(dot)COM(dot)

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(at)EXAMPLE(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2007-11-06 16:58:05 Re: Fix pg_dump dependency on postgres.h
Previous Message Zdenek Kotala 2007-11-06 13:22:09 Fix pg_dump dependency on postgres.h