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(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)?
>
> 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(at)DEFAULT(dot)REALM") and "smith(at)OTHER(dot)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