"Ross J. Reedstrom" wrote:
>
> On Fri, Nov 09, 2001 at 03:25:04PM -0500, Doug McNaught wrote:
> > Tom Lane <tgl@sss.pgh.pa.us> writes:
> >
> > > 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?
Perhaps we need some general guidelines for trusted PLs - lists of
things
to restrict, e.t.c.
Perhaps we even need something like CodeBase Principals from
Netscape/Javascript ?
Or just more fine-grained PRIVILEGEs ?
The python way of defining restricted execution is quite flexible in
what
to allow. In Zope they used to restict even some kinds of loops and list
constructors to prevent users from shooting themselves in the foot.
They are now relaxing some restrictions, as there are too many
unrestricted ways for doing it to warrant making common operations
cumbersome.
> > Could be. FWIW, Zope (www.zope.org) allows for Python scripts, created
> > and managed through the web, that run in a "sandbox" with many of the
> > same restrictions as PG puts on untrusted languages--they actually
> > disallow regex matching so you can't hang the webserver thread with a
> > regex that backtracks forever.
Are there any plans to disallow regex matching in postgreSQL as well ???
AFAIK there are simpler ways to hog a DB server as anyone writing
SQL queries can tell you ;)
A more reliable approach for DB server may be establishing per-user
memory/time/cpu quotas and just rolling back queries that exceed them.
> > Might be worthhhile for the plpython folks to take a look at Zope.
>
> And it took _forever_ to convince the Zope folks to put it in, for this
> very reason. Those who wanted python scripts (through the web interface,
> as opposed to through the filesystem) had to jump through all the hoops
> to make it safe enough.
-----------------
Hannu