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

From Tom Lane
Subject Re: Parsing of pg_hba.conf and authentication inconsistencies
Date
Msg-id 4550.1217695740@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parsing of pg_hba.conf and authentication inconsistencies  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Parsing of pg_hba.conf and authentication inconsistencies  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> Idle thought: maybe what would really make sense here is a "lint"
>> for PG config files,

> I like this idea.

> postgres --check-hba-file /path/to/hba.conf
> postgres --check-conf-file /path/to/postgresql.conf

> (I think it's better to reuse the same postmaster executable, because
> that way it's easier to have the same parsing routines.)

I'd go for just
postgres --check-config -D $PGDATA

(In a reload scenario, you'd edit the files in-place and then do this
before issuing SIGHUP.)

Reasons:

1. Easier to use: one command gets you all the checks, and you can't
accidentally forget to check the one config file that's gonna give
you problems.

2. An in-place check is the only way to be sure that, for instance,
relative-path 'include' directives are okay.

3. To implement the suggested check on role/database validity, the code
is going to need to pull in the flat-file copies of pg_database etc.
(Or try to contact a live postmaster, but that won't work when you don't
have one.)  So it needs access to $PGDATA in any case.

4. There might be usefulness in cross-checking different config files,
so examining a single one out of context just seems like the wrong
mindset.
        regards, tom lane


pgsql-hackers by date:

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