Re: krb_match_realm

Henry B. Hotz wrote:
>
> On Nov 1, 2007, at 1:40 PM, Magnus Hagander wrote:
>
>> Henry B. Hotz wrote:
>>> Thank you very much. This helps, but I'm still evaluating how much.
>>>
>>> I *can* point at one problem though: you do a strchr(gbuf.value, '@')
>>> and then error out if there isn't a Kerberos realm there. In fact that
>>> is exactly the default username of at least one of the GSSAPI
>>> implementations I've tested if the realm is the same as the local
>>> default realm.
>>
>> Eh, so how do we then determine the difference between local realm and
>> no realm given?
>
> Well, what I've seen is: no realm given if and only if the default
> local realm matches the realm for the GSSAPI username. I don't think
> that's guaranteed.

Irrk. Very much irrk.

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

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?

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

> Well, it's not a high priority for me, but there is a GSSAPI mechanism
> called SPKM which uses X500-syle names (X509 certificate subject names
> to be precise). If we use gss_name_compare() properly then it should
> "just work".

I'm unsure if PostgreSQL in general is prepared to deal with such
usernames. You'd certainly have to verify that stuff before anything
would "just work".

//Magnus