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.
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.
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?
//Magnus
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
