Re: Possible major bug in PlPython (plus some other ideas) - Mailing list pgsql-hackers

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


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

> Kevin Jacobs <jacobs@penguin.theopalgroup.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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026