Re: plpython implementation - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: plpython implementation
Date
Msg-id CAGTBQpbPaJE4bH8W8ARN0WZwRurULNRWDCBVdjiN48buR7x+Pg@mail.gmail.com
Whole thread Raw
In response to Re: plpython implementation  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: plpython implementation
Re: plpython implementation
List pgsql-hackers
On Sun, Jun 30, 2013 at 9:45 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-06-30 14:42:24 +0200, Szymon Guz wrote:
>> On 30 June 2013 14:31, Martijn van Oosterhout <kleptog@svana.org> wrote:
>>
>> > On Sun, Jun 30, 2013 at 02:18:07PM +0200, Szymon Guz wrote:
>> > > > python does not any any sort of reliable sandbox, so there is no
>> > plpython,
>> > > > only plpythonu - hence only one interpreter per backend is needed.
>> > > >
>> > > Is there any track of the discussion that there is no way to make the
>> > > sandbox? I managed to create some kind of sandbox, a simple modification
>> > > which totally disables importing modules, so I'm just wondering why it
>> > > cannot be done.
>> >
>> > http://wiki.python.org/moin/SandboxedPython
>> >
>> > This is the thread I was thinking of:
>> > http://mail.python.org/pipermail/python-dev/2009-February/086401.html
>> >
>> > If you read through it I think you will understand the difficulties.
>> >
>> thanks for links. I was thinking about something else. In fact we don't
>> need full sandbox, I think it would be enough to have safe python, if it
>> couldn't import any outside module. Wouldn't be enough?
>>
>> It seems like the sandbox modules want to limit many external operations,
>> I'm thinking about not being able to import any module, even standard ones,
>> wouldn't be enough?
>
> python
>>> open('/etc/passwd', 'r').readlines()

Not only that, the CPython interpreter is rather fuzzy about the
division between interpreters. You can initialize multiple
interpreters, but they share a lot of state, so you can never fully
separate them. You'd have some state from the untrusted interpreter
spill over into the trusted one within the same session, which is not
ideal at all (and in fact can be exploited).

In essence, you'd have to use another implementation. CPython guys
have left it very clear they don't intend to "fix" that, as they don't
consider it a bug. It's just how it is.



pgsql-hackers by date:

Previous
From: Jon Nelson
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Next
From: Nicholas White
Date:
Subject: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls