Re: Why pg_hba not in table?

Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:
> On Tue, 2006-02-07 at 15:37, Michael Fuhr wrote:
>> On Tue, Feb 07, 2006 at 03:24:01PM -0500, Tom Lane wrote:
>>> One other small point is the bootstrapping problem: if you can't get
>>> into the database to modify the config table, you've got trouble.
>>
>> Hence MySQL's --skip-grant-tables option; if you've locked yourself
>> out then you have to disable security entirely to get back in and
>> fix the problem. With a configuration that you can edit from outside
>> the database, you can usually get back in without having to punch
>> as big a hole.

> And you can change pg_hba.conf on the fly, so you don't have to restart
> a 24/7 database because you locked the superuser out.

If your back were against the wall, you could probably hand-edit the
flat-file version of the permission file enough to let yourself in
without shutting down the postmaster. It might not be as user-friendly
to edit as the current pg_hba.conf, but it'd still be flat ASCII I expect.

Also, we already have various scenarios in which dropping down to a
standalone backend is the only recovery path --- deleting the last
superuser role is a good example. So I'm not sure we should insist
that the connection permission file/table has to be any more robust
against superuser stupidity.

The case that I am most worried about is the new-installation scenario:
what will the startup default be, and how hard will be it be to fix it
if you don't like it? This is a big problem for first-timers already,
and we mustn't make it worse. But perhaps there's an opportunity here
to make it better.

regards, tom lane