Case insensitive usernames

"Magnus Hagander" <mha@sollentuna.net> writes:

I would like to see a GUC variable to enable case insensitive usernames.
Would a patch for such a thing be accepted?

No, not any more than it would be for any other SQL identifiers. See
(many, many) past threads.

regards, tom lane

I would like to see a GUC variable to enable case

insensitive usernames.

Would a patch for such a thing be accepted?

No, not any more than it would be for any other SQL identifiers. See
(many, many) past threads.

Yes, I've seen the many past threads on that ;-) I figured it might be
acceptable for just usernames.

Not sure if it's worth it ;-), but perhaps I should clearify what I
mean. I don't actually mean "case insensitive usernames". I mean
case-folding the username to lowercase once it has been received on the
server. Not sure if that makes a difference for you, but at least now
I've explained what I really meant.

Another way to help in this particular case would be to have libpq on
win32 only force-lowercase the username IF it was retreived from the
system (but not when manually specified). Then if this was done the
kerberos username-matching code would just have to be relaxed to be case
insensitive (which it really should be, because AFAIK kerberos is
supposed to be case insensitive), and the system itself can stay case
sensitive. (I still think a generic solution would be better, but this
would solve *my* problems and those of a couple of others I've heard of
who are running on win32)

Would this be acceptable instead?

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:

Another way to help in this particular case would be to have libpq on
win32 only force-lowercase the username IF it was retreived from the
system (but not when manually specified).

Well, I personally don't care how bizarrely the Win32 port behaves ;-)
so I won't complain if something like that happens. You should think
twice though about whether introducing this inconsistency is going to
be a net win, or whether it'll just move the confusion someplace else.

Then if this was done the
kerberos username-matching code would just have to be relaxed to be case
insensitive (which it really should be, because AFAIK kerberos is
supposed to be case insensitive),

This however bothers me; it seems like a potential security hole (create
kerberos principal FOO, use it to break into Foo's account). Or does
kerberos guarantee FOO and Foo are the same?

regards, tom lane

Another way to help in this particular case would be to

have libpq on

win32 only force-lowercase the username IF it was retreived

from the

system (but not when manually specified).

Well, I personally don't care how bizarrely the Win32 port
behaves ;-) so I won't complain if something like that
happens. You should think twice though about whether
introducing this inconsistency is going to be a net win, or
whether it'll just move the confusion someplace else.

Windows is case-insensitive to usernames. Always has been, and I really
don't think it's about to change considering M$'s deal with backwards
compatiblity. I doubt if this would surprise anybody - at least anybody
on the win32 platform.

Actualyl, what usually surprises people is that GetUserName() returns
the case of the username *as the user entered it at login*, and *NOT* as
the administrator entered it in the Active Directory. Which can be said
to be a bug depending on how you look at it, but from a "username is
case insensitive" perspective it doesn't matter.

Note that we wouldn't case-change a userid that is actually specified by
the user (in the connectino string, on the commandline to psql).

Then if this was done the
kerberos username-matching code would just have to be relaxed to be
case insensitive (which it really should be, because AFAIK

kerberos is

supposed to be case insensitive),

This however bothers me; it seems like a potential security
hole (create kerberos principal FOO, use it to break into
Foo's account).

Actually, to be specific, if you case-fold it he could get into "foo"
but not "Foo".

Or does kerberos guarantee FOO and Foo are the same?

Did some further checking, and it turns out this depends on the KDC. All
KDCs are required to be case sensitive no the *REALM*. But I can't find
any documented requirements on the principal - just signs that different
KDCs treat it differently. Windows AD KDC for example is insensitive,
whereas I think it looks like MIT is case sensitive.

Which brings me back to thinking a GUC is the way to deal with that -
you'll definitly know what kind of KDC you have when you set up
Kerberos. But perhaps this GUC should be for "permit case-insensitive
kerberos principals" and not "case-insensitive usernames". And it would
just control the comparison between kerberos principal and user-supplied
username. The user-supplied username would still be what's used in any
access to the database, regardless of case.

Reasonable?

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:

Which brings me back to thinking a GUC is the way to deal with that -
you'll definitly know what kind of KDC you have when you set up
Kerberos. But perhaps this GUC should be for "permit case-insensitive
kerberos principals" and not "case-insensitive usernames". And it would
just control the comparison between kerberos principal and user-supplied
username. The user-supplied username would still be what's used in any
access to the database, regardless of case.

That would work for me as long as the default is case-sensitive; the
other seems too likely to be a security hazard. (And it had better be
documented that way, too: "DO NOT turn this on unless you are certain
you are using a case-insensitive KDC.")

What will we call the GUC? kerberos_case_insensitive_principals
seems a bit, um, verbose.

regards, tom lane

Which brings me back to thinking a GUC is the way to deal

with that -

you'll definitly know what kind of KDC you have when you set up
Kerberos. But perhaps this GUC should be for "permit

case-insensitive

kerberos principals" and not "case-insensitive usernames". And it
would just control the comparison between kerberos principal and
user-supplied username. The user-supplied username would still be
what's used in any access to the database, regardless of case.

That would work for me as long as the default is
case-sensitive; the other seems too likely to be a security
hazard. (And it had better be documented that way, too: "DO
NOT turn this on unless you are certain you are using a
case-insensitive KDC.")

Fine with me - you'll need to tweak the default principal name anyway to
work with the windwos KDC, so you're giong there anyawy. It's just a
matter of documenting it.

What will we call the GUC? kerberos_case_insensitive_principals
seems a bit, um, verbose.

All other kerberos parameters are krb_ and not kerberos_, so that saves
a bit :) How about just "krb_case_insensitive"? Or "krb_case_ins_princ"?

//Magnus