"John D. Burger" <john@mitre.org> writes:
> Someone talked about the postmaster having to be "at arms' length"
> from the actual tables. But I was looking at the postmaster code,
> and it seems to fork a new backend as soon as select indicates
> there's a new request, without checking authorization or anything
> first. So why can't the new backend query the user table as normal?
> Even if shared buffers are trashed, that'll only take down the new
> backend, not the original postmaster, right?
Well, the current design is that the postmaster has a copy of the flat
file in memory, which is inherited by backends across the fork(), and
so they can query it at small cost. For the normal situation where
the list of users isn't changing very rapidly, this is probably faster
than your suggestion would be. The issue to make it work like you
suggest is that there's not presently any way to query tables until
*after* you have selected and connected to a particular database.
So you'd still need a flat file representing pg_database, plus it's
unclear how you'd implement some of pg_hba.conf's options like
"samegroup".
Since the tables you need to touch are all shared, it's conceivable that
this could be hacked around, but it seems awfully messy. Another
consideration is that this'd significantly increase the amount of work
done before validating that the connection request is authorized, thus
perhaps making it easier to mount a DOS attack on the postmaster (though
admittedly a blackhat with access to the postmaster port can probably
cause trouble anyway just from the "fork bomb" effect).
regards, tom lane