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

I'm going to do this today (Kevin, I'm not stepping on your toes, am I?)

I have some other problems with the module to be addressed (there are
about a million, or at least a dozen ways to get it to return Null pointers
to the backend, crash the backend, and cause a general shared mem
corruption message from the postmaster).

-Brad

* Bruce Momjian (pgman@candle.pha.pa.us) [011112 00:41]:
> 
> 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, Pennsylvania 19026
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html