On 03/11/2014 07:41 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> The docs say:
>> db_user_namespace causes the client's and server's user name
>> representation to differ. Authentication checks are always done with
>> the server's user name so authentication methods must be configured
>> for the server's user name, not the client's. Because md5 uses the
>> user name as salt on both the client and server, md5 cannot be used
>> with db_user_namespace.
>> Is that the only major issue?
> That's one major issue.
>
> Another one is the hacky way of distinguishing global from per-db users
> (ie, user must append @ to log in as a global user). I'd love to get rid
> of that requirement, but not sure how. Would it be all right for the
> server to first probe for user@db and then for just user, or vice versa?
user@db first, I think. I guess that means don't name your global users
the same as db-specific users. Maybe we should prevent a conflict? Or if
we allow a conflict then only require user@ in conflicting cases.
> How would this integrate with pg_hba.conf?
Not sure.
>
>> Why not have the server strip out the @db part if this is on?
> Hmm ... that's a thought. IIRC, the client doesn't actually know that
> this is going on, it just sends the user name, and hashes against that
> too. If the server remembered the bare user name it could hash against
> that as well.
>
> At least, that would work for db-local usernames. It *doesn't* work for
> global names, because the client side has no idea that the @ ought to not
> be counted for hashing. Again, if we could get rid of that convention,
> it'd be far less messy.
Right.
>
> A possible objection would be that changing the definition of what to hash
> would invalidate existing MD5 password hashes; but since MD5 passwords
> have never been allowed with db_user_namespace names anyway, that doesn't
> seem very forceful.
Agreed.
>
>> If we made this an initdb-time setting rather than a
>> GUC then we'd remove the problems caused by turning this on and off.
> Why do we need to restrict that?
>
>
Oh, probably a thinko in my part. I thought the setting would affect the
stored password, but now I think about it some more I see it doesn't.
I think we might be on the track of something useful here.
cheers
andre