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
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
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
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
"value_of(PGUSER)@value_of(krb_match_realm)" then you need to
that string, gss_import_name() it, and then gss_compare_name() the
imported name with the authenticated name that GSSAPI already gave
I know the API overhead of doing that is a PITA, but that's what's
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
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
I assume this is to take care of the fact that Microsoft Kerberos
case insensitive name matching (contrary to the standard and the
Kerberos implementations out there). I suspect issues there, but it
will be 3-6 months before I will have an environment where I can
test this. Most likely, the way to handle this is by figuring out
case Microsoft uses for each name inside the protocol and then
pre-mapping to that case before feeding things to (non-Microsoft)
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
intended level of Windows/Unix compatibility, but I don't expect
issues. In other words I'm not even going to think about it until
easy for me to investigate.
Note that it's turned *off* by default, so it shouldn't even affect
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
Attached patch implements krb_match_realm for krb5, gssapi and
complaint from Henry. Comments welcome.
Working on documentation which will of course be ready when it's
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
that it used to support, and the comment clearly states that it was
broken for the really complex scenarios anyway - something nobody
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