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
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 |