Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

From: David Fetter <david(at)fetter(dot)org>
To: Amir Rohan <amir(dot)rohan(at)zoho(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hacker mailing list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files
Date: 2015-10-14 16:41:46
Message-ID: 20151014164146.GA2582@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-10-14 17:00:35 Re: Foreign join pushdown vs EvalPlanQual
Previous Message Andres Freund 2015-10-14 16:38:35 Re: INSERT ... ON CONFLICT documentation clean-up patch