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
>
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? |
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 |