Re: Possible major bug in PlPython (plus some other ideas)

Kevin Jacobs <jacobs(at)penguin(dot)theopalgroup(dot)com> writes:
> I have noticed a possibly major issues in Plpython that may need to be
> addressed before 7.2 is released:

> 1) If Plpython is installed as a trusted language, and from what little I
> can glean from the documentation, it should not have any filesystem access.
> However, the default behavior of the restricted execution environment
> being used allows read-only filesystem access.

I agree, this is not good. If it's easy to patch, please submit a
patch.

What worries me is not so much this particular hole, which is easily
plugged now that we know about it, as that it suggests that Python's
idea of a restricted environment is considerably less restricted than
we would like. Perhaps there are other facilities that need to be
turned off as well?

The alternative we could consider is to mark plpython as untrusted for
7.2, until someone has time for a more complete review of possible
security problems.

> I have some other suggestions that may not be appropriate for the 7.2
> release, but think should be addressed before too long:

This would all be good stuff to address in 7.3 or further in the future.
As far as I'm concerned, all the PL languages except plpgsql are barely
out of the "proof of concept" stage; they all need a lot of work from
interested people to bring them to the "industrial strength" stage.
If you want to be one of those people, step right up!

> 6) [Very low priority] Its not insane to consider a Plpython procedure
> that spawns off a Python thread to do background processing tasks.
> This is obviously something that will only be possible in an untrusted
> version of the interpreter. Also, if the SPI interface is thread-safe,
> then it may be useful to release the Python interpreter lock around
> some of the SPI calls.

SPI is not thread-safe; in fact no part of the backend is thread-safe
or designed for multithreading at all. This one I'd view with great
wariness.

regards, tom lane