Re: Parsing of pg_hba.conf and authentication inconsistencies - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Parsing of pg_hba.conf and authentication inconsistencies
Date
Msg-id 20080803125815.GS16005@tamriel.snowman.net
Whole thread Raw
In response to Re: Parsing of pg_hba.conf and authentication inconsistencies  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Parsing of pg_hba.conf and authentication inconsistencies  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
* Magnus Hagander (magnus@hagander.net) wrote:
> For pg_hba.conf, I don't see that as a very big problem, really. It
> doesn't (and shouldn't) modify any "external" variables, so it should be
> as simple as parsing the new file into a completely separate
> list-of-structs and only if it's all correct switch the main pointer
> (and free the old struct).

I'm in agreement with this approach.  Allowing a config which won't
parse properly to completely break access to a running database is
terrible.  It just doesn't come across to me as being all that difficult
or complex code for pg_hba.conf.

> Yes, I still think we should do the "simple parsing" step at HUP time.
> That doesn't mean that it wouldn't be a good idea to have one of these
> check-config options that can look for conflicting options *as well*, of
> course. But I'm getting the feeling I'm on the losing side of the debate
> here...

A little extra code in the backend is well worth fixing this foot-gun.
The concerns raised so far have been "who will write it?" and "what if
it has bugs?".  Neither of these are particularly compelling arguments
when you've already offered to write and bug-test it (right, Magnus? :).
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Parsing of pg_hba.conf and authentication inconsistencies
Next
From: Magnus Hagander
Date:
Subject: Re: Parsing of pg_hba.conf and authentication inconsistencies