Skip site navigation (1) Skip section navigation (2)

Re: plpython improvements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sven <sven(at)spam(dot)pri(dot)ee>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Hannu Krosing <hannu(at)tm(dot)ee>, Marko Kreen <markokr(at)gmail(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: plpython improvements
Date: 2006-06-17 15:47:46
Message-ID: 15429.1150559266@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Sven <sven(at)spam(dot)pri(dot)ee> writes:
> If this approach is not satisfactionary and assertion predetection is
> still requested, only solution I see is to catch signal SIGABRT, set
> flag, longjmp back and report error.
> But I really don't like it.

No, ignoring SIGABRT is surely right out.

It suddenly strikes me though that we are being too picky.  The reason
(which I admit having forgotten) is that plpython only comes in an
untrusted variant.  That means that anyone writing plpython functions
is already a database superuser, and has much more direct means of
crashing the backend if he chooses to.  So the idea that this python bug
constitutes a security threat seems overblown.

If there ever is a future Python release with a new sandbox mechanism,
enabling resurrection of the trusted language, it would presumably
contain the bug fix.

Obviously we should document the problem in the plpython documentation
("don't try to use this feature with python versions before XXX"), but
I'm not any longer convinced that we have to reject this patch on
security grounds.

[ Whether the patch is any good is a separate question ;-).  I have
not reviewed it. ]

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Peter BrantDate: 2006-06-17 17:25:37
Subject: Re: [Win32] Problem with rename()
Previous:From: SvenDate: 2006-06-17 06:05:15
Subject: Re: plpython improvements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group