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.

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.


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.

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.

(FWIW, it works perfectly fine in my test setups, so I'd really like to
know why this won't work)

I may be able to flag specific failures, as I've done here, but I'm sure I can't imagine all the ways that evading the standard might cause problems. Perhaps that's not helpful or not what you want, but it's all I can do.

I also notice you have some code to do case insensitive name matching. I assume this is to take care of the fact that Microsoft Kerberos does case insensitive name matching (contrary to the standard and the other
Kerberos implementations out there).  I suspect issues there, but it
will be 3-6 months before I will have an environment where I can easily test this. Most likely, the way to handle this is by figuring out what
case Microsoft uses for each name inside the protocol and then
pre-mapping to that case before feeding things to (non-Microsoft) GSSAPI.

Yes, it's for supporting Active Directory. It's there in the same way
it's there for krb5.

I don't regard the case mapping issues as serious. We may not have the intended level of Windows/Unix compatibility, but I don't expect other issues. In other words I'm not even going to think about it until it's
easy for me to investigate.

Note that it's turned *off* by default, so it shouldn't even affect you.

Not my current concern. If I find a problem, then I'll be in a position to define how it ought to be done (*IF* it needs to be done differently).

Attached patch implements krb_match_realm for krb5, gssapi and sspi per
complaint from Henry. Comments welcome.

Working on documentation which will of course be ready when it's
committed :)

Oh, and it changes the krb username handling to be the same as the
gssapi one. I've never heard of anybody actually using the other version
that it used to support, and the comment clearly states that it was
broken for the really complex scenarios anyway - something nobody has
complained about.

Well, *I* complained about it.  ;-)

Um, not sure we're talking about the same thing. I know you complained
about the inability to match realm, but did you complain about the
inability to use things like full X.500 names as usernames?


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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to