Re: plpgsql by default

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: plpgsql by default
Дата
Msg-id 20060411204944.GA411@fetter.org
обсуждение исходный текст
Ответ на Re: plpgsql by default  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: plpgsql by default  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Apr 11, 2006 at 04:35:05PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.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@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666                             Skype: davidfetter

Remember to vote!


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Support Parallel Query Execution in Executor
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Support Parallel Query Execution in Executor