Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files - Mailing list pgsql-hackers

From David Fetter
Subject Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files
Date
Msg-id 20151014164146.GA2582@fetter.org
Whole thread Raw
In response to Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files  (Amir Rohan <amir.rohan@zoho.com>)
Responses Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files
List pgsql-hackers
On Wed, Oct 14, 2015 at 01:52:21AM +0300, Amir Rohan wrote:
> On 10/14/2015 01:12 AM, Alvaro Herrera wrote:
> > Amir Rohan wrote:
> >> On 10/14/2015 12:14 AM, Alvaro Herrera wrote:
> >>> Amir Rohan wrote:
> >>>
> >>>> I've been considering that. Reusing the parser would ensure no errors
> >>>> are introduces by having a different implementation, but on the other
> >>>> hand involving the pg build in installation what's intended as a
> >>>> lightweight, independent tool would hurt.
> >>>> Because it's dubious whether this will end up in core, I'd like
> >>>> "pip install pg_confcheck" to be all that is required.
> >>>
> >>> Maybe just compile a single file in a separate FRONTEND environment?
> >>
> >> You mean refactoring the postgres like rhass means? could you elaborate?
> >>
> >> I believe most people get pg as provided by their distro or PaaS,
> >> and not by compiling it.
> > 
> > I mean the utility would be built by using a file from the backend
> > source, just like pg_xlogdump does.  We have several such cases.
> > I don't think this is impossible to do outside core, either.
> 
> I've considered "vendoring", but it seems like enough code surgery
> be involved to make this very dubious "reuse". The language is simple
> enough that writing a parser from scratch isn't a big deal hard, and
> there doesn't seem much room for divergent parsing either.

Such room as there is seems worth eliminating if possible.  There's
even a formal name for this issue, which attackers can use, although
the implications as a source of subtle bugs in the absence of an
attacker seem more pertinent right now.

https://www.google.com/?q=parse%20tree%20differential%20attack

> So, the only question is whether reusing the existing parser will
> brings along some highly useful functionality beyond an AST and
> a battle-tested validator for bools, etc'. I'm not ruling anything
> out yet, though.

I suspect that having a single source parser, however painful now,
will pay large dividends later.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: INSERT ... ON CONFLICT documentation clean-up patch
Next
From: Robert Haas
Date:
Subject: Re: Foreign join pushdown vs EvalPlanQual