Re: 8.3 GSS Issues

On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote:

> * Henry B. Hotz (hotz(at)jpl(dot)nasa(dot)gov) wrote:
>> 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.

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.

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

See note about authentication vs authorization in last email.

> It doesn't strike me as terribly complex or hard to do but it
> certainly
> goes beyond the what is currently implemented for GSS in 8.3, and what
> exists currently for krb5. It's also something which could,
> technically, be added later. I do think it would be better done now
> though, if possible, since otherwise we would have to default to the
> current sub-par behaviour for quite some time (if not forever).
>
> Thanks,
>
> Stephen

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu