I've been looking into what it would take to eliminate the flat file for
pg_auth info. The implication of doing that is that authentication has
to be postponed until inside InitPostgres(), where we can read the
actual system catalogs instead.
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. That's perfectly doable; the main downside to it
is that if the shared relcache file were missing, we'd be reduced to
seqscan searches of these files, which could be pretty darn unpleasant
for role membership searches. However, the shared relcache file should
hardly ever be missing, and standard pg_hba.conf setups (with the role
column always ALL) don't result in role membership checks anyway. So
I'm leaning to plan B here.
Another issue is that currently, option switches supplied via PGOPTIONS
are processed at entry to PostgresMain (unless they are for SUSET GUC
variables). If we retained that behavior then they'd be applied before
authentication occurred. This worries me, though I can't immediately
point to a problem case. I'd be inclined to postpone the processing of
all user-supplied switches until after InitPostgres. This would
simplify the logic in PostgresMain, too, since we'd not have to process
SUSET variables separately from others. The only real downside I can
see is that it would make -W (post_auth_delay) pretty much useless for
its intended purpose of assisting debugging of InitPostgres-time
problems. We might as well remove it and just rely on pre_auth_delay.
This point is only of interest to hackers, and not all that often even
to us, so I don't feel that it's a critical objection.
So the disadvantages of not using the flat file for authentication
seem to boil down to
* more cycles expended before we can reject a bad username/password
* could be slow in the uncommon case that the shared relcache file is missing
* debugging InitPostgres problems will get more inconvenient
As against this, we'd be getting rid of a bunch of klugy, slow code with
assorted failure points.
Comments?
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
