Re: 8.3 GSS Issues

On Thu, Oct 25, 2007 at 05:39:37PM -0700, Henry B. Hotz wrote:
>
> On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote:
>
> >* Henry B. Hotz (hotz(at)jpl(dot)nasa(dot)gov) wrote:

> >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.

I know what you want, that's fairly obvious. I'm only asking about *how* to
do it the best way.

> >>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.
> >
> >This isn't unexpected for PG as the current krb5 support does
> >this. I'm
> >not a big fan of it but at the same time I don't feel it's
> >justification
> >to drop it from 8.3. Having it only allow the default realm would
> >be an
> >option which could work in 8.3, imv.
>
> I don't think the fact that the existing krb5 code does the wrong
> thing (and can't be used in an environment with cross-realm
> agreements) is justification for doing the wrong thing in a new
> capability. The code in my original patch would do the latter
> (default realm only).
>
> More precisely: if you do a gss_import_name() on "smith" and
> "smith(at)DEFAULT(dot)REALM" you get the same internal representation, and
> gss_compare_name() will tell you they're the same. Also
> gss_compare_name() will tell you "smith(at)OTHER(dot)REALM" is different
> from either of the first two.

Wouldn't using a specific parameter like krb_match_realm=YOUR.REALM that
you set in the config file be more flexible? In that it actually allows
scenarios like server/resource domains (not sure how common they are in
unix krb setups, but they're certainly not unfamiliar in the Windows AD
world)?

> If we don't use gss_compare_name(), or some similar mechanism, to
> compare connection names to PG usernames, then I don't think GSSAPI
> support should be included in 8.3.

I think that's a horrible idea, given that it works perfectly fine the way
it is now for the vast majority of users.

That said, we should certainly fix it in one way or another for 8.3. But if
that fails, I see no reason at all to pull the feature.

> >Longer term (since it's likely too
> >late to be accepted now), as I think has been discussed in the
> >past, PG
> >could really use a .k5login-esque, either admin-only (ala
> >pg_hba.conf /
> >ident map) or per-user (some sort of ALTER ROLE that a user could
> >do on
> >himself?), mapping functionality.
>
> There has been discussion of a general mapping layer between
> authentication names and authorization/role names. I think that's
> the way to go. I haven't thought about who or where the
> administration of the mapping ought to be.

Yeah, I agree that something like that would be a good long-term solution.

> 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.

Do you have an URL for this? Or is it a book one has t buy?

//Magnus