Re: [GENERAL] Security implications of (plpgsql) functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Security implications of (plpgsql) functions
Date
Msg-id 24855.1035216162@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] Security implications of (plpgsql) functions  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Security implications of (plpgsql) functions
Next
From: Joe Conway
Date:
Subject: Re: [GENERAL] Security implications of (plpgsql) functions