Re: Parsing of pg_hba.conf and authentication inconsistencies

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Is there any actual gain by not doing the parsing in the postmaster,
>
> Define "parsing". There's quite a lot of possible errors in pg_hba
> that it would be totally unreasonable for the postmaster to detect.

Parsing as in turning into a struct with clearly defined parts. Like
what type it is (host/local/hostssl), CIDR mask, auth method and parameters.

> We could catch some simple problems at file load time, perhaps,
> but those usually aren't the ones that cause trouble for people.

It would catch things like typos, invalid CIDR address/mask and
specifying an auth method that doesn't exist. This is the far most
common errors I've seen - which ones are you referring to?

> On the whole, I am against putting any more functionality into the
> main postmaster process than absolutely has to be there. Every
> new function you put onto it is another potential source of
> service-outage-inducing bugs.

True.

But as a counterexample, we have a whole lot of code in there to do the
same for GUC. Which can even call user code (custom variables), no? Are
you also proposing we should look at getting rid of that?

>> I've also noticed that authentication methods error out in different
>> ways when they are not supported.
>
> Yeah, that's something that should be made more consistent.
>
>
> Idle thought: maybe what would really make sense here is a "lint"
> for PG config files, which you'd run as a standalone program and
> which would look for not only clear errors but questionable things
> to warn about. For instance it might notice multiple pg_hba.conf
> entries for the same IP addresses, check whether an LDAP server
> can be connected to, check that all user/group/database names
> used in the file actually exist, etc. These are things that we'd
> certainly not put into any load- or reload-time tests.

That would also be a valuable tool, but IMHO for a slightly different
purpose. To me that sounds more in the line of the tool to "tune/suggest
certain postgresql.conf parameters" that has been discussed earlier.

It would have to be implemented as a SQL callable function or so in
order to make it usable for people doing remote admin, but that could
certainly be done.

It would still leave a fairly large hole open for anybody editing the
config file and just HUPing the postmaster (which a whole lot of people
do, since they're used to doing that to their daemon processes)

//Magnus