Magnus Hagander wrote:
> Tom Lane wrote:
> > Magnus Hagander <magnus@hagander.net> writes:
> >> I am unsure of exactly where this thing hacks into the authentication
> >> stream, but is it really only MD5 that fails?
> >
> > The problem with md5 is that the username is part of the encryption salt
> > for the stored password, so changing it breaks that --- the client will
> > hash the password with what it thinks the username is, but the stored
> > password in pg_authid is hashed with what the server thinks the username
> > is.
> >
> > You might be right that some other auth methods have an issue too,
> > but md5 is the only one anyone's ever reported a problem with. That
> > might or might not just represent lack of testing.
>
> Right.
>
> But say GSSAPI for example. It will get the username from an external
> source, and compare this to whatever the user specified. If we rewrite
> what the user specified, we loose.
>
> But maybe you can work around that by using pg_ident.conf, so *both* the
> identities gets rewritten.
>
> Not sure I care enough to dive into what it would actually mean. My
> guess is that it's very uncommon to use db_user_namespace in any of
> these scenarios (in fact I think it's very uncommon to use it at all,
> but even more uncommon in these cases)
The documentation changes highlight that we are going to validate for
most external authentications using the server username, so the external
authentication has to be set up to use that server username. Were the
docs not clear on that? Do I need a mention of db_user_namespace in the
authentication docs?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
