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
|
| Список | 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 по дате отправления: