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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: 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 16:44:41
Message-ID: 25182.1035218681@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message MT 2002-10-21 16:50:01 Can't write lock file
Previous Message Joe Conway 2002-10-21 16:39:51 Re: [GENERAL] Security implications of (plpgsql) functions

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-10-21 16:52:10 Re: Please help
Previous Message Tom Lane 2002-10-21 16:40:54 Re: autocommit vs TRUNCATE et al