On Nov 9, 2007, at 5:24 AM, Magnus Hagander wrote:
On Tue, 2007-11-06 at 18:10 -0800, Henry B. Hotz wrote:
On Nov 6, 2007, at 6:27 AM, Magnus Hagander wrote:
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.
*sigh* Yeah, maybe we have to live with it.
Yeah, that's kind of where I'm going - it's certainly not perfect, but
it's the least bad one.
Given this, I'll go ahead with the current version of the patch,
and we
can consider making better changes at a later time assuming we figure
them out. It's still a lot better than what's in there now, and it
*will* cover the vast majority of cases.
I'll address Stephens comments separately.
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.
Well, it *might* work to do a memcmp() of tolower() of the blobs.
Right, but if they're defined as blobs, that's even less safe than we
did before.
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.
That can't be entirely true. Maybe it's true for Microsoft's RC4
enctype, but it can't be true for the des-cbc-md5 enctype. The
protocol runs with some case, and the question is what case it uses
when it matters.
Haven't protocol-traced it, but our systems use des-cbc-md5. It's the
only one I managed to get working with pg server running on Linux and
clients running on Windows. And in this case, the case insensitive/
case
preserving behavior is a fact.
I was thinking that the case of the principal affects the protocol,
but actually I guess that's only true for the string-to-key
function. That would affect a user's ability to get the initial tgt,
but not how service tickets are handled. Given case preservation,
that would guarantee the correct case for a non-Windows client (for
both Windows and Unix servers), but nowhere else.
Kind of blows the SSPI/GSSAPI compatibility that's supposed to
exist. I think I may start a discussion of this on an IETF list in
case people want to update the GSSAPI standard.
I suppose you win. Just do a gss_display_name() and do a case
insensitive compare. I can't do any independent verification.
*bleah* Can you leave the compare inside gssapi if it's not case
insensitive though?
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.
Hmmm. See above. It isn't possible to make it irrelevant
everywhere, unless you only use RC4. Vista uses AES so it looses
that loophole though.
Yeah, I haven't tried Vista at all. I've only done 2000, XP and 2003.
I wonder if case conversion is the right way to create compatibility
with GSSAPI though. If the user always comes in with a specific case
then shouldn't we instead find a way to make sure the PG user is
created with the corresponding case? There are several ways you can
test for the existence of a user in a Kerberos service, for example
kinit with a garbage password will give different errors.
That's why we have krb5_caseninsens_users - to let the user choose it.
//Magnus
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
