Re: krb_match_realm

On Tue, 2007-11-06 at 18:10 -0800, Henry B. Hotz wrote:
> On Nov 6, 2007, at 6:27 AM, Magnus Hagander wrote:
> > 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.
>
> *sigh* Yeah, maybe we have to live with it.

Yeah, that's kind of where I'm going - it's certainly not perfect, but
it's the least bad one.

Given this, I'll go ahead with the current version of the patch, and we
can consider making better changes at a later time assuming we figure
them out. It's still a lot better than what's in there now, and it
*will* cover the vast majority of cases.

I'll address Stephens comments separately.

> >> 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.
>
> Well, it *might* work to do a memcmp() of tolower() of the blobs.

Right, but if they're defined as blobs, that's even less safe than we
did before.

> >> 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.
>
> That can't be entirely true. Maybe it's true for Microsoft's RC4
> enctype, but it can't be true for the des-cbc-md5 enctype. The
> protocol runs with some case, and the question is what case it uses
> when it matters.

Haven't protocol-traced it, but our systems use des-cbc-md5. It's the
only one I managed to get working with pg server running on Linux and
clients running on Windows. And in this case, the case insensitive/case
preserving behavior is a fact.

> >> 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.
>
> Hmmm. See above. It isn't possible to make it irrelevant
> everywhere, unless you only use RC4. Vista uses AES so it looses
> that loophole though.
>
Yeah, I haven't tried Vista at all. I've only done 2000, XP and 2003.

> I wonder if case conversion is the right way to create compatibility
> with GSSAPI though. If the user always comes in with a specific case
> then shouldn't we instead find a way to make sure the PG user is
> created with the corresponding case? There are several ways you can
> test for the existence of a user in a Kerberos service, for example
> kinit with a garbage password will give different errors.

That's why we have krb5_caseninsens_users - to let the user choose it.

//Magnus