Re: 8.3 GSS Issues

Henry B. Hotz 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.
>>
>> 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)?
> 
> Yes and no.  It certainly would have made it easier to test my original
> patch since the server was in a test realm and I couldn't use my normal
> production identity.  I'd imagine deployments where the users are in a
> different realm from the servers are somewhat common.

Yes, that is the "resource domain" model that at least MS suggested you
use earlier on - they may still do so.


> The counter is that (if done naively) it would prevent you from
> supporting users from multiple realms at all.  I never completely tested
> this, but I think with my original patch you could define both "smith"
> (== "smith@DEFAULT.REALM") and "smith@OTHER.REALM" as users to PG.  They
> wouldn't be the same user (which you might want), but you could support
> both of them.

Well, you could turn it off, and use those usernames then, no?


> Is there any (other) code in PG that would barf on long usernames that
> contain "@" and/or "."?

I don't think there is any risk with it containing that, but there is a
max length of a username somewhere of course...


>>> 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.
> 
> If this isn't fixed then PG will never be a supported infrastructure
> service at JPL the way MySQL currently is.  I had hoped to use the
> GSSAPI support as a feature to pry some people away from MySQL, but
> without the ability to integrate into a multi-realm infrastructure this
> won't fly.  Of course even with proper support it still may never
> happen, so that isn't a threat.

Sure, but that's no reason to pull it from 8.3 if it can only be fixed
in 8.4. It's a good reason to work towards having it fixed in 8.3,
certainly, but not a reason to pull it if it isn't there.

FWIW, I'm fairly certain I can have a match_realm parameter done for beta3.

//Magnus