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

I would like to have a patch for this into 7.2 because it is a security
problem.

---------------------------------------------------------------------------

> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026