I'm back on the warpath about $SUBJECT. (Aside from any other reason to
do it, it occurs to me that we really need to get rid of the flat files
for Hot Standby. Otherwise we'd need some way to keep them up to date
during WAL replay.) I wrote earlier:
> The easy way to do it would be to postpone authentication until after we
> have selected and entered a database. At that point we could use existing
> code such as is_member_of_role(). There is a security disadvantage to
> that: you would find out whether the database name you'd given was valid
> before any authentication check occurred. Since database names are often
> also user names, that would give a brute-force attacker a leg up on
> discovering valid user names. Plan B is to use the same techniques for
> reading pg_authid and pg_auth_members as InitPostgres is now using for
> reading pg_database.
I've thought of an easier way to handle this: if the given database name
is invalid, connect to database "postgres" instead, and perform
authentication using normal access to the pg_auth catalogs. If
authentication succeeds, *then* throw the error about nonexistent
database. If "postgres" is not there, we'd still expose existence
of the original database name early, but how many installations don't
have that? (I thought about trying template1 and/or template0 as
fallbacks, but that's probably not a good thing. Backends that are
waiting on a client for authentication would pose a DOS problem for
sessions trying to do CREATE DATABASE, if they're connected to those.)
Because this would all happen before the checks on permission to connect
to the DB, it would still work as desired if, say, postgres exists but
is marked not datallowconn. So anyone who was paranoid enough to not
want DB postgres to be accessible could mark it that way instead of
deleting it.
This would avoid duplicating the is_member_of_role() logic so I'm
tempted to do it like this, but wanted to see if anyone had objections
or better ideas.
regards, tom lane
