Re: [GENERAL] Security implications of (plpgsql) functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Marcin Owsiany <marcin(at)owsiany(dot)pl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] Security implications of (plpgsql) functions
Date: 2002-10-21 16:02:42
Message-ID: 24855.1035216162@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Crash reproduced here.

FWIW, I got a regular "out of memory" elog. But I can see that this
would depend on the relative sizes of data limit and stack limit on
a particular platform.

> I think we need to fix this by
> either setting a limit in the amount of function recursion, or allowing
> only the offending backend to crash without forcing all the other
> backends to crash.

Unless you can think of a way to distinguish stack overflow from other
kinds of SIGSEGV, I don't think we can avoid a system-wide restart.
Reducing stack overflow to a plain elog(ERROR) would be really nice,
but how?

A depth limit for PL-function recursion is perhaps feasible, but I can't
say that I care for it a whole lot ... anyone have better ideas?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeffrey Bohmer 2002-10-21 16:08:52 Re: Buffers and MacOS X
Previous Message Richard Huxton 2002-10-21 16:02:18 Re: Tutorial on postgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeffrey Bohmer 2002-10-21 16:08:52 Re: Buffers and MacOS X
Previous Message D. Hageman 2002-10-21 16:02:16 Re: Postgresql and multithreading