Bruce Momjian wrote:
> 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?
AFAICS, the changes only say MD5 doesn't work. I think it should be made
more clear.
And yes, it probably makes sense to put it around the authentication
docs as well as a warning to people - that's where they'll go looking if
something doesn't work.
//Magnus