Re: 8.3 GSS Issues

On Oct 26, 2007, at 12:56 AM, Magnus Hagander wrote:

> 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@jpl.nasa.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@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.

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.

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

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

>>> 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 those on the periphery: the PG protocol already carries the PG  
username, and the Kerberos and GSSAPI auth methods carry the  
authentication name.  If you define the PG username to be the  
authorization name then you have a pretty standard architecture.

If anyone has used a kerberized ssh then you have a similar split.   
You can kinit as "A" and then "ssh B@server".  If you have put "A"  
into ~B/.k5login then you get in without a password prompt.

>> 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 to buy?

Sorry.  For the non-Solaris users out there, all their documentation  
is available at http://docs.sun.com/.

Rather than drilling down through their web site it's easier to just  
Google for what you want.  I see that if you just put in the doc  
number you get links for purchasing the book and reporting bugs in  
it, and downloading the examples, but not what you want.  If you  
Google for 816-4863.pdf you get directly to it though.  No doubt  
there are other variations that would work, and if you looked on  
following pages of the first search you ought to find it there too.

One of the problems with discussing Google search terms on open lists  
like this is that if you want to use the same search terms later you  
wind up getting your own emails instead of what you really want.  |-P

Don't sweat the document too much.  It's a bit neurotic in its  
explanations.  Once you have the general idea the Sun man pages (also  
on docs.sun.com) are more useful.  The two referenced outlines  
reflect what's recommended by the RFC's.  AFAIK Sun has the best  
documentation outside of the RFC's.

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