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

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, 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 18:17:47
Message-ID: 1035224267.3750.10.camel@camel
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

I've seen the idea of "user resource limits" bandied about before as a
way to address these problems; depending on implementation that might be
the way to go.

Robert Treat

On Mon, 2002-10-21 at 12:44, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
> > Is there any way to recognize infinite recursion by analyzing the saved
> > execution tree -- i.e. can we assume that a function that calls itself, with
> > the same arguments with which it was called, constitutes infinite recursion?
>
> A bulletproof solution would be equivalent to solving the halting
> problem, I believe. The test you mentioned is easily defeated by
> recursing between two functions. Also, a would-be instigator of
> DOS doesn't need *infinite* recursion; it could be quite finite and
> still blow out your stack. For example ask for factorial(10million)
> where factorial is defined in the traditional recursive way...
>
> regards, tom lane
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Williams, Travis L, NPONS 2002-10-21 18:22:44 slow update & index question
Previous Message Raymond Lukas 2002-10-21 17:55:13 client side software for windows, where?

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-10-21 18:54:57 Re: autocommit vs TRUNCATE et al
Previous Message Larry Rosenman 2002-10-21 17:59:38 Re: Please help