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