Re: Silent failure with invalid hba_file setting

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Thom Brown <thom(at)linux(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Silent failure with invalid hba_file setting
Date: 2011-10-19 05:22:08
Message-ID: CABUevEyzNXzOU3TQnC6o4cZc9XCOySvu1BgRc3rEE1DgxYVbWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Oct 19, 2011 6:21 AM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On tis, 2011-10-18 at 18:38 -0400, Tom Lane wrote:
> >> Well, an actually empty pg_hba.conf file would have the same problem,
> >> and it's pretty hard to see any situation where it would be useful to
> >> start the postmaster and not let it accept any connections. Should we
> >> add a check to consider it an error if the file doesn't contain at
least
> >> one HBA record?
>
> > If you try to connect and it doesn't find a record, it will tell you.
>
> Yeah, but the damage is already done. I see the main practical benefit
> of this being to prevent accidental loading of a trashed pg_hba file.

Yeah, definitely. It's very much a pita when you accidentally do that with a
syntax error on <8.4, %. So while I haven't actually managed to hit his
specific problem myself, +1 for this approach.

> > I wouldn't add extra special checks for that. It might not be
> > completely unreasonable to have a standby that no one can connect to,
> > for example.
>
> Well, you couldn't monitor its state then, so I don't find that example
> very convincing. But if you were intent on having that, you could
> easily set up a pg_hba file containing only "reject" entries.
>

Yeah, seems reasonable to put a (very) small amount of extra work in the
path of a very uncommon scenario in order to protect users in the common
one...

/Magnus

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2011-10-19 06:31:10 Re: loss of transactions in streaming replication
Previous Message Tom Lane 2011-10-19 05:10:02 Re: (patch) regression diffs on collate.linux.utf8 test