From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, andrew(at)supernews(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: plpgsql by default |
Date: | 2006-04-11 20:49:45 |
Message-ID: | 20060411204944.GA411@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 11, 2006 at 04:35:05PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > Rather than debate how turing complete SQL is, look at the real
> > issue: is a compromised system with plPGSQL installed more
> > dangerous than a compromised system without plPGSQL. As far as I
> > can see, it's not.
>
> You're disregarding the possibility that plpgsql itself is the
> source of a security hole ...
So might SQL.
> More realistically, though, the theoretical point that you can do
> arbitrary calculations by turning loops into recursive SQL functions
> is mostly just theoretical, and the reason is that you won't be able
> to loop very many times before running out of stack space. (On my
> machine it looks like you can recurse a trivial SQL function only
> about 600 times before hitting the default stack limit.) If you
> have an exploit that involves moderate amounts of calculation within
> the server --- say, brute force password cracking --- the
> availability of a PL will render that exploit actually practical,
> whereas with only SQL functions to work with it won't be.
The function I sent memoizes to a table, which avoids the stack space
problem you mentioned.
Cheers,
D
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-04-11 20:49:48 | Re: Support Parallel Query Execution in Executor |
Previous Message | Jim C. Nasby | 2006-04-11 20:38:58 | OS cached buffers (was: Support Parallel Query Execution in Executor) |