Re: 8.3 GSS Issues

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

> * Henry B. Hotz (hotz@jpl.nasa.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@DEFAULT.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@OTHER.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.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu