On Fri, Nov 02, 2007 at 11:23:30AM -0700, Henry B. Hotz wrote:
> >>>>I'm not entirely sure what the intended semantics of  
> >>>>krb_match_realm
> >>>>are, but if you're trying to match the GSSAPI-authenticated name  
> >>>>against
> >>>>"value_of(PGUSER)@value_of(krb_match_realm)" then you need to  
> >>>>construct
> >>>>that string, gss_import_name() it, and then gss_compare_name() the
> >>>>imported name with the authenticated name that GSSAPI already  
> >>>>gave you.
> >>>>I know the API overhead of doing that is a PITA, but that's  
> >>>>what's going
> >>>>to work.
> >>>
> >>>Why?
> >>
> >>Because if we're using the GSSAPI then we need to use the properties
> >>defined by the GSSAPI, and not depend on observed behavior of  
> >>specific
> >>implementations of specific mechanisms.  Otherwise things will be
> >>non-portable or unreliable in ways that may be non-obvious.
> >>
> >>In particular gss_display_name() produces a character string intended
> >>for display to a human being.  It is *NOT* intended for access  
> >>control.
> >>As another example, Heimdal gss_display_name() puts '\' escapes in  
> >>front
> >>of special characters in the username.  I don't think it's worth  
> >>writing
> >>special case code for that either.
> >
> >Ok. I can see that point. However, if you have those characters in  
> >your
> >username, you may have other problems as well :-)
> Yeah.  Not many people put spaces inside usernames.

I think we can easily get away with not covering that case.

> >Is there some other way to actually get the username from gss? I mean,
> >if we *didn't* get it from the startup packet, how would we ever be  
> >able
> >to determine what user logged in?
> gss_export_name(), but what it returns is supposed to be an opaque  
> binary blob.
> It's guaranteed to produce a unique, canonicalized name based on the  
> specific mechanism in use.  It is suitable for memcmp().  The  
> exported name will re-import.  Section 3.10 of rfc 2744 describes all  
> this, and appears to be clearer than the Sun document I pointed you  
> at.  Certainly it's more concise.  YMMV.

Hmm. But it doesn't serve our purpose.

> memcmp() on exported names will only be true if everyone uses the  
> same gss mechanism.  (OK, the only one we care about is kerberos.)   
> In contrast it's possible that gss_compare_name() would say that  
> "uid=smith,ou=People,dc=example,dc=com" is the same as  

No, memcmp()ing two separate strings (userid + match realm) with an opaque
binary blob certainly won't help us at all.

> >>The standard defines two ways to do comparisons for access  
> >>control.  We
> >>should use one of them.  Anything else is going to be more work  
> >>and less
> >>reliable.
> >
> >What's the other way then?
> >
> >Last I checked there was no way to do case insensitive matching on
> >gss_compare_name() but I could be on the wrong docs? Finding any  
> >kind of
> >consistent docs for this stuff isn't exactly easy.
> >Because we *must* have the ability to do case insensitive matching, or
> >it *will* break on Windows.
> No gss_compare_name() is case sensitive.  I think the way to do it is  
> to know what case Microsoft is going to use and pre-map everything to  
> that case (before you do a gss_import_name()).  I *think* Microsoft  
> will use upper case for the service name so we will need to change  
> from "postgres" to "POSTGRES" as the default name in service  
> principals.  I've seen places where they may be using lower case  
> realm names (which makes *NO* sense to me).

No. Microsoft will send you whatever case the user put into the login box
when he logged into windows. It's case-*preserving*, but case-insensitive. 

However, AD itself requires uppercase service name, but that's a different

> Absent an environment where I can actually look at all these things,  
> my only point of reference is mod_auth_kerb, and the issues reported  
> with it.  I know an upper case "HTTP" is needed to interoperate with  
> windows clients.  An upper case realm name seems to be OK, as is a  
> lower case server name in the second component.  The actual usernames  
> seem to be lower case, but that's not the concern of the  
> mod_auth_kerb developers since the deployer just needs to put in  
> whatever matches.

The usernames depend on what the client puts in. It's generally a big
problem because a lot of krb-aware applications can't deal with it.

> I assume in AD you can't create both "smith" and "Smith", but can you  
> create the latter at all?  If you do, does AD remember the case for  
> display purposes?  Here at JPL usernames are lower case, and I don't  
> think we allow anything special but hyphens in them, so I'm not  
> likely to see a lot of the possible corner cases.

You can and it remembers. But it has no effect on what is sent ni the
kerberos packets - what's sent there is what the user typed in. Yes, that
sucks bad, but that's how it is.

> I think you can upper case the service name, lower case the server  
> name, upper case the realm name, and lower case the user name.  If  
> you can create "Smith" in AD and the user gets authenticated as  
> "[EMAIL PROTECTED]" at the protocol level then that won't work though.

Which is how it is :-(

>From what I can tell, the least bad way to do it is still the patch that
sits in the queue now (pending changes based on Stephens comments, but
those are a differnt thing)


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to