Обсуждение: plpythonu

Hello,
someone can tell me if is secure to create external python modules and
import them to functions/procedures/triggers to use?

I am doing the following:

function/procedure/trigger:

CREATE OR REPLACE FUNCTION tabela_be_i_tg_fx() RETURNS trigger AS $body$
from dbfunctions.postgres.pg_trigger import TestTrigger as fx
fe = fx()
return fe.execute(args=TD["args"], event=TD["event"], when=TD["when"],
level=TD["level"], name=TD["name"], relid=TD["relid"], new=TD["new"],
old=TD["old"], pl_py=plpy)
$body$
LANGUAGE plpythonu;


at python module I have:


class TestTrigger(object):
    def execute(self, args, event, when, level, name, relid, new, old,
pl_py):
        new["group_name"]='__modified__'
        return 'MODIFY'


all this works properly (on windows and linux), but I don't know if is
the correct way to use plpythonu, and if I will have future problems.

Another question is that I have read in some discussion list (old
message year 2003) the possibility of plpython be removed from
postgresql, this information is valid yet?

sorry bad English

Thank's for all

--
Alexandre da Silva
Analista de Sistemas - Bacharel em Sistemas de Informação (2003-2007)

Alexandre da Silva wrote:
> Hello,
> someone can tell me if is secure to create external python modules and
> import them to functions/procedures/triggers to use?

Its fine as long as you trust the users with write access to your PYTHONP=
ATH.

> Another question is that I have read in some discussion list (old
> message year 2003) the possibility of plpython be removed from
> postgresql, this information is valid yet?

plpython !=3D plpythonu.

plpython was the 'secure' sandboxed version. The Python devs gave up
supporting any sort of sandboxing feature in Python declaring it impossib=
le.
plpythonu is unrestricted, so if you have the ability to create plpythonu=

stored procedures you effectively have full filesystem access on your
database server as the user your database is running as. So don't put
open('/etc/passwd','w') in your plpythonu code.

--=20
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/

On Jan 18, 2008, at 7:48 AM, Stuart Bishop wrote:
> plpython !=3D plpythonu.
>
> plpython was the 'secure' sandboxed version. The Python devs gave up
> supporting any sort of sandboxing feature in Python declaring it
> impossib=
> le.

Someone should definitely take a look at this:  http://
sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html

That guy claims he's locked down the python interpreter there.

Erik Jones

DBA | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

On 1/18/08, Erik Jones <erik@myemma.com> wrote:
> On Jan 18, 2008, at 7:48 AM, Stuart Bishop wrote:
> > plpython !=3D plpythonu.
> >
> > plpython was the 'secure' sandboxed version. The Python devs gave up
> > supporting any sort of sandboxing feature in Python declaring it
> > impossib=
> > le.
>
> Someone should definitely take a look at this:  http://
> sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html
>
> That guy claims he's locked down the python interpreter there.

Interesting.  But the problem has never been in locking down
the interpreter vX.Y, but locking down interpreter vX.Y+1, when
previously work was done on vX.Y.  Without upstream developers
cooperation this has been too painful.

So the interesting thing in the posting is not that he succeeded
locking Python down, but that he is pushing the patch to core.

--
marko

I'm a fan of unsecured languages in the database.
Obviously they should only be used by people who understand the difference.
I wouldn't want python locked down.
That would prevent so many different external functions that can now be integrated into the database.

Among other things that I currently do with plpythonu is a function that reads a template file,
populates it with data and saves the file to the server. It then FTPs the file to another server.
It certainly can all be done outside of the database, but it is so much easier (and less maintenance)
to include it as a function.

Sim


Erik Jones wrote:
>
> On Jan 18, 2008, at 7:48 AM, Stuart Bishop wrote:
>> plpython !=3D plpythonu.
>>
>> plpython was the 'secure' sandboxed version. The Python devs gave up
>> supporting any sort of sandboxing feature in Python declaring it
>> impossib=
>> le.
>
> Someone should definitely take a look at this:
> http://sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html
>
> That guy claims he's locked down the python interpreter there.
>
> Erik Jones
>
> DBA | Emma®
> erik@myemma.com
> 800.595.4401 or 615.292.5888
> 615.292.0777 (fax)
>
> Emma helps organizations everywhere communicate & market in style.
> Visit us online at http://www.myemma.com
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faq
>

Sim Zacks wrote:
> I'm a fan of unsecured languages in the database.
> Obviously they should only be used by people who understand the difference.
> I wouldn't want python locked down.
> That would prevent so many different external functions that can now
> be integrated into the database.
>
> Among other things that I currently do with plpythonu is a function
> that reads a template file, populates it with data and saves the file
> to the server. It then FTPs the file to another server.  It certainly
> can all be done outside of the database, but it is so much easier (and
> less maintenance) to include it as a function.

Having the trusted language does not mean you lose the untrusted one.
We have both plperl and plperlu, for example.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.