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 20080803131148.GT16005@tamriel.snowman.net
Whole thread Raw
In response to Re: Parsing of pg_hba.conf and authentication inconsistencies  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
* Magnus Hagander (magnus@hagander.net) wrote:
> I think it'd be reasonable to refuse starting if the config is *known
> broken* (such as containing lines that are unparseable, or that contain
> completely invalid tokens), whereas you'd start if they just contain
> things that are "probably wrong". But picking from your previous
> examples of "more advanced checks",  there are lots of cases where
> things like overlapping CIDR address ranges are perfectly valid, so I
> don't think we could even throw a warning for that - unless there's a
> separate flag to enable/disable warnings for such a thing.

Agreed.  Making sure the config can parse is different from parsable but
non-sensible.  It's ridiculously easy to mistakenly add a line w/ a
single character on it or something equally bad when saving a file
that's being modified by hand.  That's a simple check that should be
done on re-hup and the broken config shouldn't be put in place.

I certainly agree that we should *also* have a way to just check the
config, so that can be built into init scripts and whatnot.  I don't
think having one precludes having the other, and I'm pretty confident we
could find a way to not duplicate the code and have things be clean.
Thanks,
    Stephen

pgsql-hackers by date:

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