Re: plpgsql by default

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: plpgsql by default
Дата
Msg-id 20060411201301.GS49405@pervasive.com
обсуждение исходный текст
Ответ на Re: plpgsql by default  (David Fetter <david@fetter.org>)
Ответы Re: plpgsql by default  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Apr 10, 2006 at 11:02:50PM -0700, David Fetter wrote:
> On Tue, Apr 11, 2006 at 12:47:03AM -0400, Tom Lane wrote:
> > "Joshua D. Drake" <jd@commandprompt.com> writes:
> > > What does enabling plpgsql do via access that you can't just do from an 
> > > SQL query?
> > 
> > SQL isn't Turing-complete
> 
> With all due respect, SQL *is* Turing-complete.  Here's a little demo
> of this Turing-completeness:

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.
SQL makes it just as easy to DoS the machine (just select a large
cartesian product). plPGSQL doesn't provide any inherent ability to
damage data outside the database, and it doesn't make trashing the
database any easier than it is with plain SQL. About the only thing I
can think of that plPGSQL lets you do that SQL doesn't is to raise
arbitrary errors, but that hardly seems like much of an increased risk.

There is some limited truth to the argument that plPGSQL potentially
opens more potential for a machine to be compromised, but much less so
than allowing connections from any IP does for example. I haven't seen
any real reason not to include plPGSQL by default, especially since
removing whatever slight risk exists is a simple DROP LANGUAGE away.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


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

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Get explain output of postgresql in Tables
Следующее
От: Kris Jurka
Дата:
Сообщение: Re: [PATCHES] schema-qualified SET CONSTRAINTS