Andrew Dunstan <and...@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?
How would this integrate with pg_hba.conf?
> 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.
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.
> 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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
