I've worked with the Pl/Python code in the past and will see about removing
rexec and making it an untrusted language.  Last time I looked, it didn't
look particularly difficult.  I've set aside some time next week, so stay
tuned.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com


Wed, 18 Jun 2003 21:28:26 -0400 (EDT)
Kevin Jacobs <jacobs@penguin.theopalgroup.com>
PlPython
On Wed, 18 Jun 2003, Kevin Jacobs wrote:
> I've worked with the Pl/Python code in the past and will see about removing
> rexec and making it an untrusted language.  Last time I looked, it didn't
> look particularly difficult.  I've set aside some time next week, so stay
> tuned.

Attached is a patch that removes all of the RExec code from plpython from
the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
untrusted language in createlang.  Please let me know if there are any
problems.

Best regards,
-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com
Fri, 20 Jun 2003 10:29:43 -0400 (EDT)
Kevin Jacobs <jacobs@penguin.theopalgroup.com>
Re: PlPython
Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> Attached is a patch that removes all of the RExec code from plpython from
> the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
> untrusted language in createlang.

I am inclined to rename plpython to plpythonu, by analogy to pltclu.
The advantage of doing so is that (a) the name change makes it somewhat
more obvious that there's a fundamental behavioral change, and (b)
assuming that the Python folk someday figure out a secure version of
RExec, we'd want to reinstitute the trusted version of plpython, but
perhaps not take away the untrusted one.

On the other hand, this would create headaches for people who are trying
to load dump files that declare plpython or contain plpython-language
functions.  I can't think of any non-kluge solution to this (kluge
solutions would include putting special-case code into CREATE FUNCTION
to change 'plpython' to 'plpythonu' ...)

Comments?

			regards, tom lane

Sun, 22 Jun 2003 18:29:07 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
Hi Tom,

> I am inclined to rename plpython to plpythonu, by analogy to pltclu.
> The advantage of doing so is that (a) the name change makes it somewhat
> more obvious that there's a fundamental behavioral change, and (b)
> assuming that the Python folk someday figure out a secure version of
> RExec, we'd want to reinstitute the trusted version of plpython, but
> perhaps not take away the untrusted one.

Sounds good.

> On the other hand, this would create headaches for people who are trying
> to load dump files that declare plpython or contain plpython-language
> functions.

But since plpython is untrusted now this probably would not work anyway...

> I can't think of any non-kluge solution to this (kluge
> solutions would include putting special-case code into CREATE FUNCTION
> to change 'plpython' to 'plpythonu' ...)

I think this would only make it more confusing. Changing plpython from trusted
to untrusted is a big change, so some extra attention from the db-admin and
users is good IMHO.

Bye,
Sander.


Mon, 23 Jun 2003 10:32:12 +0200
"Sander Steffann" <steffann@nederland.net>
Re: PlPython 
On Sun, 22 Jun 2003, Tom Lane wrote:
> Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> > Attached is a patch that removes all of the RExec code from plpython from
> > the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
> > untrusted language in createlang.
> 
> I am inclined to rename plpython to plpythonu, by analogy to pltclu.

In 7.4, I would do this.  In the next 7.3.x release, I would leave the name
as is, but still make plpython untrusted.  It will cause some problems, but
safety and integrity are more important here.  After all, the alternative is
to drop the PL entirely.

> On the other hand, this would create headaches for people who are trying
> to load dump files that declare plpython or contain plpython-language
> functions.  I can't think of any non-kluge solution to this (kluge
> solutions would include putting special-case code into CREATE FUNCTION
> to change 'plpython' to 'plpythonu' ...)

Allowing both plpython and plpythonu to be added as separate languages
should be sufficient.  This way, we effectively deprecate plpython, or at
least defer its final removal until the restricted execution problem can be
solved.  I hope to start looking into exactly what needs to be done to
restore that functionality in the next few weeks.

Thanks,
-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com


Mon, 23 Jun 2003 06:50:54 -0400 (EDT)
Kevin Jacobs <jacobs@penguin.theopalgroup.com>
Re: PlPython 

For 7.4 (which I expect is the patch's target) it might be
best to make both names point to the same thing with a
clear release note that says that they are the same thing
and that plpython[u] is now untrusted.

That will give people a bit a time to reload their 
existing functions.

elein

On Sunday 22 June 2003 15:29, Tom Lane wrote:
> Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> > Attached is a patch that removes all of the RExec code from plpython from
> > the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
> > untrusted language in createlang.
> 
> I am inclined to rename plpython to plpythonu, by analogy to pltclu.
> The advantage of doing so is that (a) the name change makes it somewhat
> more obvious that there's a fundamental behavioral change, and (b)
> assuming that the Python folk someday figure out a secure version of
> RExec, we'd want to reinstitute the trusted version of plpython, but
> perhaps not take away the untrusted one.
> 
> On the other hand, this would create headaches for people who are trying
> to load dump files that declare plpython or contain plpython-language
> functions.  I can't think of any non-kluge solution to this (kluge
> solutions would include putting special-case code into CREATE FUNCTION
> to change 'plpython' to 'plpythonu' ...)
> 
> Comments?
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
> 
> 

-- 
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


Mon, 23 Jun 2003 13:30:59 -0700
elein <elein@varlena.com>
Re: PlPython
elein  <elein@varlena.com> writes:
> For 7.4 (which I expect is the patch's target) it might be
> best to make both names point to the same thing with a
> clear release note that says that they are the same thing
> and that plpython[u] is now untrusted.

I don't know any way to actually do that, though.  If we put two entries
in pg_language then functions created in plpython will stay associated
with that entry.  That'd probably be the worst of all possible worlds,
since a person looking at pg_language would quite reasonably assume that
plpython was still trusted and the untrusted plpythonu was just an
addition.  (Especially if he happened to know that such an addition was
planned long ago.)  You could shoot yourself in the foot pretty badly
with such a misunderstanding :-(

The behavior that I think would be most useful would be to automatically
transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION
... LANGUAGE "plpythonu".  Which we could do with an ugly hack in CREATE
FUNCTION (ugly, but no worse than things we've done to index opclass
names, for example).  But it could be too confusing.

			regards, tom lane

Mon, 23 Jun 2003 16:53:22 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
Tom Lane wrote:
> elein  <elein@varlena.com> writes:
> > For 7.4 (which I expect is the patch's target) it might be
> > best to make both names point to the same thing with a
> > clear release note that says that they are the same thing
> > and that plpython[u] is now untrusted.
> 
> I don't know any way to actually do that, though.  If we put two entries
> in pg_language then functions created in plpython will stay associated
> with that entry.  That'd probably be the worst of all possible worlds,
> since a person looking at pg_language would quite reasonably assume that
> plpython was still trusted and the untrusted plpythonu was just an
> addition.  (Especially if he happened to know that such an addition was
> planned long ago.)  You could shoot yourself in the foot pretty badly
> with such a misunderstanding :-(
> 
> The behavior that I think would be most useful would be to automatically
> transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION
> ... LANGUAGE "plpythonu".  Which we could do with an ugly hack in CREATE
> FUNCTION (ugly, but no worse than things we've done to index opclass
> names, for example).  But it could be too confusing.

You mean in gram.y?  Yes, I think that is our only choice.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 23 Jun 2003 17:04:20 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] PlPython
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> The behavior that I think would be most useful would be to automatically
>> transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION
>> ... LANGUAGE "plpythonu".  Which we could do with an ugly hack in CREATE
>> FUNCTION (ugly, but no worse than things we've done to index opclass
>> names, for example).  But it could be too confusing.

> You mean in gram.y?  Yes, I think that is our only choice.

Actually I think it should be in functioncmds.c.  I moved the special
kluges for opclass names out of gram.y and into indexcmds.c awhile ago.
But that's just an implementation detail --- we really need to still be
thinking about whether this is the behavior we want or not.  Someone
else made a fair point that such a kluge might not actually make life
any easier for reloading dump files.  If we do it that way, then if a
non-superuser tries to CREATE FUNCTION ... LANGUAGE "plpython" it will
fail (not being trusted) and so he's got no hope of loading the dump
without editing anyway.  If that's true, there's not much point in
introducing a hidden kluge.

			regards, tom lane

Mon, 23 Jun 2003 17:13:18 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PlPython 

I thought there would be a relatively clear way
to alias them both to the same language library for
a release or two.  But I see your point on transitioning.
Clear notice is really important.

plpython should be phased out if it is not replaced
within a release or two.

If only the change could be transparent to those
people who are not using any untrusted features.

Maybe it is better to break everyone's plpython functions
in 7.4.  That would certainly make sure everyone heard
of the change from trusted to untrusted.  But explanations
of what exactly that means should also be included in the 
release notes.

elein

PS: I've built and tested the plpython patch against
7.3.2 and am happy it does not affect the features I count
on.  I'd do it against the development release but
I can't get it to build (for other reasons).

On Monday 23 June 2003 13:53, Tom Lane wrote:
> elein  <elein@varlena.com> writes:
> > For 7.4 (which I expect is the patch's target) it might be
> > best to make both names point to the same thing with a
> > clear release note that says that they are the same thing
> > and that plpython[u] is now untrusted.
> 
> I don't know any way to actually do that, though.  If we put two entries
> in pg_language then functions created in plpython will stay associated
> with that entry.  That'd probably be the worst of all possible worlds,
> since a person looking at pg_language would quite reasonably assume that
> plpython was still trusted and the untrusted plpythonu was just an
> addition.  (Especially if he happened to know that such an addition was
> planned long ago.)  You could shoot yourself in the foot pretty badly
> with such a misunderstanding :-(
> 
> The behavior that I think would be most useful would be to automatically
> transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION
> ... LANGUAGE "plpythonu".  Which we could do with an ugly hack in CREATE
> FUNCTION (ugly, but no worse than things we've done to index opclass
> names, for example).  But it could be too confusing.
> 
> 			regards, tom lane
> 
> 

-- 
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


Mon, 23 Jun 2003 14:42:42 -0700
elein <elein@varlena.com>
Re: PlPython
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> The behavior that I think would be most useful would be to automatically
> >> transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION
> >> ... LANGUAGE "plpythonu".  Which we could do with an ugly hack in CREATE
> >> FUNCTION (ugly, but no worse than things we've done to index opclass
> >> names, for example).  But it could be too confusing.
> 
> > You mean in gram.y?  Yes, I think that is our only choice.
> 
> Actually I think it should be in functioncmds.c.  I moved the special
> kluges for opclass names out of gram.y and into indexcmds.c awhile ago.
> But that's just an implementation detail --- we really need to still be
> thinking about whether this is the behavior we want or not.  Someone
> else made a fair point that such a kluge might not actually make life
> any easier for reloading dump files.  If we do it that way, then if a
> non-superuser tries to CREATE FUNCTION ... LANGUAGE "plpython" it will
> fail (not being trusted) and so he's got no hope of loading the dump
> without editing anyway.  If that's true, there's not much point in
> introducing a hidden kluge.

Well, it does fix the super-user case, so we have to tell non-super
users to get their administrator to install it, which actually is the
right solution anyway for non-super-user installs of plpython language
modules anyway.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 23 Jun 2003 18:21:07 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] PlPython

Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

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


Kevin Jacobs wrote:
> On Wed, 18 Jun 2003, Kevin Jacobs wrote:
> > I've worked with the Pl/Python code in the past and will see about removing
> > rexec and making it an untrusted language.  Last time I looked, it didn't
> > look particularly difficult.  I've set aside some time next week, so stay
> > tuned.
> 
> Attached is a patch that removes all of the RExec code from plpython from
> the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
> untrusted language in createlang.  Please let me know if there are any
> problems.
> 
> Best regards,
> -Kevin
> 
> -- 
> --
> Kevin Jacobs
> The OPAL Group - Enterprise Systems Architect
> Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
> Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

Content-Description: 

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 23 Jun 2003 22:54:54 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: PlPython

Patch applied.  Thanks.

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


Kevin Jacobs wrote:
> On Wed, 18 Jun 2003, Kevin Jacobs wrote:
> > I've worked with the Pl/Python code in the past and will see about removing
> > rexec and making it an untrusted language.  Last time I looked, it didn't
> > look particularly difficult.  I've set aside some time next week, so stay
> > tuned.
> 
> Attached is a patch that removes all of the RExec code from plpython from
> the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
> untrusted language in createlang.  Please let me know if there are any
> problems.
> 
> Best regards,
> -Kevin
> 
> -- 
> --
> Kevin Jacobs
> The OPAL Group - Enterprise Systems Architect
> Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
> Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

Content-Description: 

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 24 Jun 2003 21:19:00 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: PlPython
Just wondering (I don't use or intend to use plpython), but why does it 
need to be marked untrusted is the rexec code has been corrected.

Bruce Momjian wrote:

>Patch applied.  Thanks.
>
>---------------------------------------------------------------------------
>
>
>Kevin Jacobs wrote:
>  
>
>>On Wed, 18 Jun 2003, Kevin Jacobs wrote:
>>    
>>
>>>I've worked with the Pl/Python code in the past and will see about removing
>>>rexec and making it an untrusted language.  Last time I looked, it didn't
>>>look particularly difficult.  I've set aside some time next week, so stay
>>>tuned.
>>>      
>>>
>>Attached is a patch that removes all of the RExec code from plpython from
>>the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
>>untrusted language in createlang.  Please let me know if there are any
>>problems.
>>
>>Best regards,
>>-Kevin
>>
>>-- 
>>--
>>Kevin Jacobs
>>The OPAL Group - Enterprise Systems Architect
>>Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
>>Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com
>>    
>>
>
>Content-Description: 
>
>[ Attachment, skipping... ]
>
>  
>
>>---------------------------(end of broadcast)---------------------------
>>TIP 2: you can get off all lists at once with the unregister command
>>    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>>    
>>
>
>  
>








Just wondering (I don't use or intend to use plpython), but why does it
need to be marked untrusted is the rexec code has been corrected.

Bruce Momjian wrote:

Patch applied.  Thanks.

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


Kevin Jacobs wrote:
  

On Wed, 18 Jun 2003, Kevin Jacobs wrote:
    

I've worked with the Pl/Python code in the past and will see about removing
rexec and making it an untrusted language.  Last time I looked, it didn't
look particularly difficult.  I've set aside some time next week, so stay
tuned.
      

Attached is a patch that removes all of the RExec code from plpython from
the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
untrusted language in createlang.  Please let me know if there are any
problems.

Best regards,
-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com
    


Content-Description: 

[ Attachment, skipping... ]

  

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Thu, 26 Jun 2003 11:35:33 -0500
DeJuan Jackson <djackson@speedfc.com>
Re: PlPython
Because rexec was considered so broken by Guido that it was removed in its 
entirety.  Hopefully some day it will be readded in a more secure form, 
and then the plpython module can be reinstated as a trusted language.

On Thu, 26 Jun 2003, DeJuan Jackson wrote:

> Just wondering (I don't use or intend to use plpython), but why does it 
> need to be marked untrusted is the rexec code has been corrected.
> 
> Bruce Momjian wrote:
> 
> >Patch applied.  Thanks.
> >
> >---------------------------------------------------------------------------
> >
> >
> >Kevin Jacobs wrote:
> >  
> >
> >>On Wed, 18 Jun 2003, Kevin Jacobs wrote:
> >>    
> >>
> >>>I've worked with the Pl/Python code in the past and will see about removing
> >>>rexec and making it an untrusted language.  Last time I looked, it didn't
> >>>look particularly difficult.  I've set aside some time next week, so stay
> >>>tuned.
> >>>      
> >>>
> >>Attached is a patch that removes all of the RExec code from plpython from
> >>the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
> >>untrusted language in createlang.  Please let me know if there are any
> >>problems.
> >>
> >>Best regards,
> >>-Kevin
> >>
> >>-- 
> >>--
> >>Kevin Jacobs
> >>The OPAL Group - Enterprise Systems Architect
> >>Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
> >>Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com
> >>    
> >>
> >
> >Content-Description: 
> >
> >[ Attachment, skipping... ]
> >
> >  
> >
> >>---------------------------(end of broadcast)---------------------------
> >>TIP 2: you can get off all lists at once with the unregister command
> >>    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> >>    
> >>
> >
> >  
> >
> 
> 


Thu, 26 Jun 2003 10:48:56 -0600 (MDT)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: PlPython
DeJuan Jackson <djackson@speedfc.com> writes:
> Just wondering (I don't use or intend to use plpython), but why does it 
> need to be marked untrusted is the rexec code has been corrected.

Now that the rexec code is gone, it MUST be marked untrusted --- this is
not a question for debate.  Installing it as trusted would be a security
hole.

			regards, tom lane

Thu, 26 Jun 2003 12:59:14 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
On Thu, 26 Jun 2003, DeJuan Jackson wrote:
> Just wondering (I don't use or intend to use plpython), but why does it 
> need to be marked untrusted is the rexec code has been corrected.

No corrected -- removed.   Rexec is and will likely remain broken for at
least one more Python release.  Thus, it was decided to remove all support
for it in Python, and consequently from PlPython.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com


Thu, 26 Jun 2003 13:04:17 -0400 (EDT)
Kevin Jacobs <jacobs@penguin.theopalgroup.com>
Re: PlPython
On Thu, 2003-06-26 at 11:59, Tom Lane wrote:
> DeJuan Jackson <djackson@speedfc.com> writes:
> > Just wondering (I don't use or intend to use plpython), but why does it 
> > need to be marked untrusted is the rexec code has been corrected.
> 
> Now that the rexec code is gone, it MUST be marked untrusted --- this is
> not a question for debate.  Installing it as trusted would be a security
> hole.

In what version is rexec removed?  v2.3?  If so, then there are
many people with Python 2.2 and even 2.1 who could still use
trusted PlPython.

-- 
+-----------------------------------------------------------+
| Ron Johnson, Jr.     Home: ron.l.johnson@cox.net          |
| Jefferson, LA  USA   http://members.cox.net/ron.l.johnson |
|                                                           |
| "Oh, great altar of passive entertainment, bestow upon me |
|  thy discordant images at such speed as to render linear  |
|  thought impossible" (Calvin, regarding TV)               |
+-----------------------------------------------------------


26 Jun 2003 12:23:27 -0500
Ron Johnson <ron.l.johnson@cox.net>
Re: PlPython
Ron Johnson <ron.l.johnson@cox.net> writes:
> In what version is rexec removed?  v2.3?  If so, then there are
> many people with Python 2.2 and even 2.1 who could still use
> trusted PlPython.

Only if they don't mind being exposed to well-publicized security holes.
If we continued to support the rexec-based version, we'd be
irresponsible to keep marking it trusted ... so there's little point in
keeping it.

			regards, tom lane

Thu, 26 Jun 2003 13:34:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
Ron Johnson <ron.l.johnson@cox.net> writes:

> On Thu, 2003-06-26 at 11:59, Tom Lane wrote:

> > Now that the rexec code is gone, it MUST be marked untrusted --- this is
> > not a question for debate.  Installing it as trusted would be a security
> > hole.
> 
> In what version is rexec removed?  v2.3?  If so, then there are
> many people with Python 2.2 and even 2.1 who could still use
> trusted PlPython.

No--rexec was removed in 2.3 because it was found to be unfixably
insecure, not because 2.3 broke anything. Earlier versions are just as
insecure.

-Doug

26 Jun 2003 13:35:07 -0400
Doug McNaught <doug@mcnaught.org>
Re: PlPython
Ron Johnson <ron.l.johnson@cox.net> writes:

> On Thu, 2003-06-26 at 11:59, Tom Lane wrote:
>> DeJuan Jackson <djackson@speedfc.com> writes:
>> > Just wondering (I don't use or intend to use plpython), but why does it 
>> > need to be marked untrusted is the rexec code has been corrected.
>> 
>> Now that the rexec code is gone, it MUST be marked untrusted ---
>> this is not a question for debate.  Installing it as trusted would
>> be a security hole.
>
> In what version is rexec removed?  v2.3?  If so, then there are many
> people with Python 2.2 and even 2.1 who could still use trusted
> PlPython.

The problem, as I understand it, is that the reason that rexec was
removed was that Guido (and others) were convinced that it wasn't
really safe in the first place.  Removing rexec was something along
the lines of "truth in advertising."  The Python folks realized that
rexec wasn't really safe, and they weren't particularly interested in
expending the time and effort to make it safe, so they removed rexec
entirely.

They could have left it in and simply patched over any problems that
were reported and then pretended that Python was actually secure in
this manner, but they didn't want to be compared to MySQL's crash-me
script.*  Leaving broken and dangerous bits in Python simply because
it would be a marketing bonus was not something the Python folks
wanted to do.

* [OK, I am making up the bit about the crash-me script, but you get
   the idea.]

In short, rexec wasn't really safe in the first place.  It just made
people feel better.

Jason

Thu, 26 Jun 2003 11:37:44 -0600
Jason Earl <jason.earl@simplot.com>
Re: PlPython
On Thu, 2003-06-26 at 12:37, Jason Earl wrote:
> Ron Johnson <ron.l.johnson@cox.net> writes:
> 
> > On Thu, 2003-06-26 at 11:59, Tom Lane wrote:
> >> DeJuan Jackson <djackson@speedfc.com> writes:
[snip]
> In short, rexec wasn't really safe in the first place.  It just made
> people feel better.

But this is America.  People don't care about facts, only feelings.
Ask any teacher that bumps up a kid's grade because "it might hurt
his self-esteem"...

-- 
+-----------------------------------------------------------+
| Ron Johnson, Jr.     Home: ron.l.johnson@cox.net          |
| Jefferson, LA  USA   http://members.cox.net/ron.l.johnson |
|                                                           |
| "Oh, great altar of passive entertainment, bestow upon me |
|  thy discordant images at such speed as to render linear  |
|  thought impossible" (Calvin, regarding TV)               |
+-----------------------------------------------------------


26 Jun 2003 13:30:19 -0500
Ron Johnson <ron.l.johnson@cox.net>
Re: PlPython
So, the issue is that rexec was supposed to be secure but it's not and 
has be removed from future versions.  Kevin has replace the calls of 
rexec with a non-secure version (maybe 'exec'), therefore the calls to 
plpython would be inherently insecure in the first place, so we have to 
make it an untrusted language.

Correct?

Kevin Jacobs wrote:

>On Thu, 26 Jun 2003, DeJuan Jackson wrote:
>  
>
>>Just wondering (I don't use or intend to use plpython), but why does it 
>>need to be marked untrusted is the rexec code has been corrected.
>>    
>>
>
>No corrected -- removed.   Rexec is and will likely remain broken for at
>least one more Python release.  Thus, it was decided to remove all support
>for it in Python, and consequently from PlPython.
>
>-Kevin
>
>  
>








So, the issue is that rexec was supposed to be secure but it's not and
has be removed from future versions.  Kevin has replace the calls of
rexec with a non-secure version (maybe 'exec'), therefore the calls to
plpython would be inherently insecure in the first place, so we have to
make it an untrusted language.

Correct?

Kevin Jacobs wrote:

On Thu, 26 Jun 2003, DeJuan Jackson wrote:
  

Just wondering (I don't use or intend to use plpython), but why does it 
need to be marked untrusted is the rexec code has been corrected.
    


No corrected -- removed.   Rexec is and will likely remain broken for at
least one more Python release.  Thus, it was decided to remove all support
for it in Python, and consequently from PlPython.

-Kevin
Thu, 26 Jun 2003 13:31:46 -0500
DeJuan Jackson <djackson@speedfc.com>
Re: PlPython


Tom Lane wrote:
> DeJuan Jackson <djackson@speedfc.com> writes:
> 
>>Just wondering (I don't use or intend to use plpython), but why does it 
>>need to be marked untrusted is the rexec code has been corrected.
> 
> 
> Now that the rexec code is gone, it MUST be marked untrusted --- this is
> not a question for debate.  Installing it as trusted would be a security
> hole.
> 

That means that there is something else untrusted in PLPython,
what is this?

Regards,
Mikhail Terekhov



Thu, 26 Jun 2003 14:39:45 -0400
Mikhail Terekhov <terekhov@emc.com>
Re: PlPython
Mikhail Terekhov <terekhov@emc.com> writes:

> Tom Lane wrote:

> > not a question for debate.  Installing it as trusted would be a security
> > hole.
> >
> 
> That means that there is something else untrusted in PLPython,
> what is this?

In PostgreSQL, an "untrusted" language is one that doesn't restrict
the user to a "safe" set of operations.  It doesn't mean "buggy".

-Doug

26 Jun 2003 14:45:07 -0400
Doug McNaught <doug@mcnaught.org>
Re: PlPython
>>Now that the rexec code is gone, it MUST be marked untrusted --- this is
>>not a question for debate.  Installing it as trusted would be a security
>>hole.
> 
> That means that there is something else untrusted in PLPython,
> what is this?
Well, basically everything else.

You are getting this backwards. Making Python a *trusted*
language *requires* something like rexec. Since we don't have
rexec anymore (it never was much good, apparently) we cannot
make Python trusted. Hence we must make it untrusted to keep
it in at all.

The point here is not whether we trust the rest of Python but
whether we have something (like rexec) that restricts the
standard Python. Only if we have that do we define a language
as "trusted".

Things would be different, of course, if an entire language
was restricted by nature. That would be a candidate for a
trusted language without needing specific add-on execution
restriction.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Thu, 26 Jun 2003 20:48:41 +0200
Karsten Hilbert <Karsten.Hilbert@gmx.net>
Re: PlPython
Thanks for the explanation. I think I understand it now.

Mikhail

Karsten Hilbert wrote:
>>>Now that the rexec code is gone, it MUST be marked untrusted --- this is
>>>not a question for debate.  Installing it as trusted would be a security
>>>hole.
>>
>>That means that there is something else untrusted in PLPython,
>>what is this?
> 
> Well, basically everything else.
> 
> You are getting this backwards. Making Python a *trusted*
> language *requires* something like rexec. Since we don't have
> rexec anymore (it never was much good, apparently) we cannot
> make Python trusted. Hence we must make it untrusted to keep
> it in at all.
> 
> The point here is not whether we trust the rest of Python but
> whether we have something (like rexec) that restricts the
> standard Python. Only if we have that do we define a language
> as "trusted".
> 
> Things would be different, of course, if an entire language
> was restricted by nature. That would be a candidate for a
> trusted language without needing specific add-on execution
> restriction.
> 
> Karsten



Thu, 26 Jun 2003 16:16:22 -0400
Mikhail Terekhov <terekhov@emc.com>
Re: PlPython


Perhaps this should be asked on the interfaces list, but...
Exactly what functions are prohibited (or acceptable)
for a pl language in PostgreSQL to become trusted?

Is the exact criteria list documented somewhere?

Since C is wide open, why is it considered trusted,
or is it?  Or are some C calls disallowed by the
function manager (this was what we did at informix,
we also enforced permissions carefully (after showing
how easy it was to break things :-) ).

My guess of the list would be:
	1. No or a restricted set of OS calls 
		(what would be the restricted set?
		 The set Keith removed?)
	2. No file system operations or strongly
	   enforced permissions on file system operations.

Elein

On Thursday 26 June 2003 11:48, Karsten Hilbert wrote:
> >>Now that the rexec code is gone, it MUST be marked untrusted --- this is
> >>not a question for debate.  Installing it as trusted would be a security
> >>hole.
> > 
> > That means that there is something else untrusted in PLPython,
> > what is this?
> Well, basically everything else.
> 
> You are getting this backwards. Making Python a *trusted*
> language *requires* something like rexec. Since we don't have
> rexec anymore (it never was much good, apparently) we cannot
> make Python trusted. Hence we must make it untrusted to keep
> it in at all.
> 
> The point here is not whether we trust the rest of Python but
> whether we have something (like rexec) that restricts the
> standard Python. Only if we have that do we define a language
> as "trusted".
> 
> Things would be different, of course, if an entire language
> was restricted by nature. That would be a candidate for a
> trusted language without needing specific add-on execution
> restriction.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 
> 

-- 
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


Fri, 27 Jun 2003 15:06:38 -0700
elein <elein@varlena.com>
Re: PlPython
C is god.  I.e. C functions run as the same user as the postmaster, and 
can do anything they want, and it takes a superuser to install functions 
written in it.

The following are (were...?) trusted languages in 7.3.3:

plpgsql
pltcl
plpython
plsql (built in)

These are the untrusted languages in 7.3.3:

pltclu
plperlu
C functions

A trusted language is basically one that lives in a box that won't let it 
do dangerous things like write files, call system calls as the postgres 
super user etc...

Explanation (still in need of editing for the final release of 7.4) are 
here:

http://developer.postgresql.org/docs/postgres/xplang.html 

On Fri, 27 Jun 2003, elein wrote:

> 
> 
> Perhaps this should be asked on the interfaces list, but...
> Exactly what functions are prohibited (or acceptable)
> for a pl language in PostgreSQL to become trusted?
> 
> Is the exact criteria list documented somewhere?
> 
> Since C is wide open, why is it considered trusted,
> or is it?  Or are some C calls disallowed by the
> function manager (this was what we did at informix,
> we also enforced permissions carefully (after showing
> how easy it was to break things :-) ).
> 
> My guess of the list would be:
> 	1. No or a restricted set of OS calls 
> 		(what would be the restricted set?
> 		 The set Keith removed?)
> 	2. No file system operations or strongly
> 	   enforced permissions on file system operations.
> 
> Elein
> 
> On Thursday 26 June 2003 11:48, Karsten Hilbert wrote:
> > >>Now that the rexec code is gone, it MUST be marked untrusted --- this is
> > >>not a question for debate.  Installing it as trusted would be a security
> > >>hole.
> > > 
> > > That means that there is something else untrusted in PLPython,
> > > what is this?
> > Well, basically everything else.
> > 
> > You are getting this backwards. Making Python a *trusted*
> > language *requires* something like rexec. Since we don't have
> > rexec anymore (it never was much good, apparently) we cannot
> > make Python trusted. Hence we must make it untrusted to keep
> > it in at all.
> > 
> > The point here is not whether we trust the rest of Python but
> > whether we have something (like rexec) that restricts the
> > standard Python. Only if we have that do we define a language
> > as "trusted".
> > 
> > Things would be different, of course, if an entire language
> > was restricted by nature. That would be a candidate for a
> > trusted language without needing specific add-on execution
> > restriction.
> > 
> > Karsten
> > -- 
> > GPG key ID E4071346 @ wwwkeys.pgp.net
> > E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> >     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> > 
> > 
> 
> 


Fri, 27 Jun 2003 16:15:03 -0600 (MDT)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: PlPython

Yes, I understand.  (And the dev docs look pretty darn good)

I was just  wondering if postgresql had a language independent
definitive list of  "dangerous" functionality, but it seems
that the trusted-ness implementation is pretty language specific.

Just for general knowledge, with python 2.1.1, I was able to 
import the following documented as "forbidden" modules.
I have only used "string" so I do NOT assume that enabling
import means that they all work.  (more testing...)

	array bisect binascii calendar cmath errno
	marshal math md5 operator pcre pickle
	random re regex sha StringIO struct
	time whrandom string

The following modules from the forbidden
list caused import errors as expected:
	zlib, codecs, mpz

I'll do some more testing and submit a more complete
doc patch if I can squeeze in the time.  Or if someone
else wants to help let me know.

elein@varlena.com

On Friday 27 June 2003 15:15, scott.marlowe wrote:
> C is god.  I.e. C functions run as the same user as the postmaster, and 
> can do anything they want, and it takes a superuser to install functions 
> written in it.
> 
> The following are (were...?) trusted languages in 7.3.3:
> 
> plpgsql
> pltcl
> plpython
> plsql (built in)
> 
> These are the untrusted languages in 7.3.3:
> 
> pltclu
> plperlu
> C functions
> 
> A trusted language is basically one that lives in a box that won't let it 
> do dangerous things like write files, call system calls as the postgres 
> super user etc...
> 
> Explanation (still in need of editing for the final release of 7.4) are 
> here:
> 
> http://developer.postgresql.org/docs/postgres/xplang.html 
> 
> On Fri, 27 Jun 2003, elein wrote:
> 
> > 
> > 
> > Perhaps this should be asked on the interfaces list, but...
> > Exactly what functions are prohibited (or acceptable)
> > for a pl language in PostgreSQL to become trusted?
> > 
> > Is the exact criteria list documented somewhere?
> > 
> > Since C is wide open, why is it considered trusted,
> > or is it?  Or are some C calls disallowed by the
> > function manager (this was what we did at informix,
> > we also enforced permissions carefully (after showing
> > how easy it was to break things :-) ).
> > 
> > My guess of the list would be:
> > 	1. No or a restricted set of OS calls 
> > 		(what would be the restricted set?
> > 		 The set Keith removed?)
> > 	2. No file system operations or strongly
> > 	   enforced permissions on file system operations.
> > 
> > Elein
> > 
> > On Thursday 26 June 2003 11:48, Karsten Hilbert wrote:
> > > >>Now that the rexec code is gone, it MUST be marked untrusted --- this is
> > > >>not a question for debate.  Installing it as trusted would be a security
> > > >>hole.
> > > > 
> > > > That means that there is something else untrusted in PLPython,
> > > > what is this?
> > > Well, basically everything else.
> > > 
> > > You are getting this backwards. Making Python a *trusted*
> > > language *requires* something like rexec. Since we don't have
> > > rexec anymore (it never was much good, apparently) we cannot
> > > make Python trusted. Hence we must make it untrusted to keep
> > > it in at all.
> > > 
> > > The point here is not whether we trust the rest of Python but
> > > whether we have something (like rexec) that restricts the
> > > standard Python. Only if we have that do we define a language
> > > as "trusted".
> > > 
> > > Things would be different, of course, if an entire language
> > > was restricted by nature. That would be a candidate for a
> > > trusted language without needing specific add-on execution
> > > restriction.
> > > 
> > > Karsten
> > > -- 
> > > GPG key ID E4071346 @ wwwkeys.pgp.net
> > > E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> > > 
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 2: you can get off all lists at once with the unregister command
> > >     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> > > 
> > > 
> > 
> > 
> 
> 

-- 
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


Fri, 27 Jun 2003 16:40:53 -0700
elein <elein@varlena.com>
Re: PlPython
elein <elein@varlena.com> writes:
> Perhaps this should be asked on the interfaces list, but...
> Exactly what functions are prohibited (or acceptable)
> for a pl language in PostgreSQL to become trusted?
> Is the exact criteria list documented somewhere?

We don't have a formal definition, but I'd say a minimum requirement
is that a function written in a trusted PL language cannot cause any
outside-the-database actions to be attempted by the backend (such as
trying to read or write any files in the server's filesystem).  A
trusted-PL language should be able to define arbitrary self-contained
computations (arithmetic, pattern-matching, or what have you), and it
should be able to access the database at the same level as regular
SQL commands.  It should not be able to bypass the SQL abstractions nor
execute any OS-level operations using the postgres user's privileges.

> Since C is wide open, why is it considered trusted,
> or is it?

It isn't.

			regards, tom lane

Fri, 27 Jun 2003 23:29:43 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
Tom Lane <tgl@sss.pgh.pa.us> writes:

> elein <elein@varlena.com> writes:
> > Exactly what functions are prohibited (or acceptable)
> > for a pl language in PostgreSQL to become trusted?
> > Is the exact criteria list documented somewhere?
> 
> We don't have a formal definition, but I'd say a minimum requirement
> is that a function written in a trusted PL language cannot cause any
> outside-the-database actions to be attempted by the backend (such as
> trying to read or write any files in the server's filesystem).  A
> trusted-PL language should be able to define arbitrary self-contained
> computations (arithmetic, pattern-matching, or what have you), and it
> should be able to access the database at the same level as regular
> SQL commands.  It should not be able to bypass the SQL abstractions nor
> execute any OS-level operations using the postgres user's privileges.

What about making network connections?  That seems less harmful than
filesystem access, and certainly could have legitimate uses.

-Doug

28 Jun 2003 10:50:06 -0400
Doug McNaught <doug@mcnaught.org>
Re: PlPython
Doug McNaught <doug@mcnaught.org> writes:
> What about making network connections?  That seems less harmful than
> filesystem access, and certainly could have legitimate uses.

Any outside-the-database operation "could have legitimate uses".  The
problem is it also has not-so-legitimate uses, and we would have no
good way to tell the difference.  So a trusted language is supposed to
be an airtight sandbox.  If you want out of the sandbox, you use an
untrusted language.

			regards, tom lane

Sat, 28 Jun 2003 11:21:35 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
Tom Lane kirjutas E, 23.06.2003 kell 01:29:
> Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> > Attached is a patch that removes all of the RExec code from plpython from
> > the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
> > untrusted language in createlang.
> 
> I am inclined to rename plpython to plpythonu, by analogy to pltclu.

...

> Comments?

could we not just make sure that plpython uses python ver < 2.x and use
plpythonu for python versions >= 2.x until a secure regex solution comes
from Guido and folks ?

I guess most plpython users would be much happier with plpython with
some minor limitations due to older version than with being forced to
use an untrusted pl altogether.

IIRC python 1.5.2 has a perfectly good RExec.

Or is there a requirement that only latest language versions are used in
pg 74 ;)

--------------
Hannu


29 Jun 2003 22:18:45 +0300
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] PlPython
Hannu Krosing <hannu@tm.ee> writes:
> could we not just make sure that plpython uses python ver < 2.x and use
> plpythonu for python versions >= 2.x until a secure regex solution comes
> from Guido and folks ?

We'd still have to mark it untrusted, so what's the point?

			regards, tom lane

Sun, 29 Jun 2003 17:18:10 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PlPython 
Tom Lane kirjutas E, 30.06.2003 kell 00:18:
> Hannu Krosing <hannu@tm.ee> writes:
> > could we not just make sure that plpython uses python ver < 2.x and use
> > plpythonu for python versions >= 2.x until a secure regex solution comes
> > from Guido and folks ?
> 
> We'd still have to mark it untrusted, so what's the point?

No we don't! The old version of plpython was perfectly OK when used with
python 1.5.x and will be so. The RExec security holes were only
introduced with new class mechanisms in python 2.x.

The version with patch which removes RExec (as Python 2.x is not
supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is
no reason to remove safe execution when using python 1.5.x.

Thus my proposition for using the old version as plpython and the new
version as plpython-u, but allowing the non-u version to be compuled
only for python v < 2.x.

-----------------
Hannu


30 Jun 2003 00:38:33 +0300
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] PlPython
Hannu Krosing <hannu@tm.ee> writes:
> The version with patch which removes RExec (as Python 2.x is not
> supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is
> no reason to remove safe execution when using python 1.5.x.

Who's still using 1.5, I guess is the question?  And are they likely
to be updating their PG installation when they're not updating Python?

			regards, tom lane

Sun, 29 Jun 2003 18:21:45 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PlPython 
Tom Lane kirjutas E, 30.06.2003 kell 01:21:
> Hannu Krosing <hannu@tm.ee> writes:
> > The version with patch which removes RExec (as Python 2.x is not
> > supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is
> > no reason to remove safe execution when using python 1.5.x.
> 
> Who's still using 1.5, I guess is the question?  And are they likely
> to be updating their PG installation when they're not updating Python?

Python is designed such that one can install and use different versions
in parallel - for example the deafult directopries for libraries are
/usr/lib/python1.5/ and /usr/lib/python2.2/ if you have installed python
1.5.x and 2.2.x, also executables are python2, python2.2 and python1.5,
with plain python being a link to one of these.

I guess that anyone who needs safe Restricted Execution will be using
1.5 at least for that purpose until RExec is fixed in 2.x.

------------------
Hannu


30 Jun 2003 01:56:27 +0300
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] PlPython
On 30 Jun 2003, Hannu Krosing wrote:
> Tom Lane kirjutas E, 30.06.2003 kell 01:21:
> > Hannu Krosing <hannu@tm.ee> writes:
> > > The version with patch which removes RExec (as Python 2.x is not
> > > supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is
> > > no reason to remove safe execution when using python 1.5.x.
> > 
> > Who's still using 1.5, I guess is the question?  And are they likely
> > to be updating their PG installation when they're not updating Python?
> 
> Python is designed such that one can install and use different versions
> in parallel - for example the deafult directopries for libraries are
> /usr/lib/python1.5/ and /usr/lib/python2.2/ if you have installed python
> 1.5.x and 2.2.x, also executables are python2, python2.2 and python1.5,
> with plain python being a link to one of these.
> 
> I guess that anyone who needs safe Restricted Execution will be using
> 1.5 at least for that purpose until RExec is fixed in 2.x.

Unless a someone steps forward to actively maintain such a configuration,
then trusted PlPython is not going to exist anymore.  The cost of getting
even the most minute detail wrong is just too high tobe left to chance.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com


Sun, 29 Jun 2003 21:54:39 -0400 (EDT)
Kevin Jacobs <jacobs@penguin.theopalgroup.com>
Re: [HACKERS] PlPython
Hannu Krosing <hannu@tm.ee> writes:
> Tom Lane kirjutas E, 30.06.2003 kell 01:21:
>> Who's still using 1.5, I guess is the question?  And are they likely
>> to be updating their PG installation when they're not updating Python?

> I guess that anyone who needs safe Restricted Execution will be using
> 1.5 at least for that purpose until RExec is fixed in 2.x.

I don't find that real compelling ...

The bottom line is that this has to get done.  I have the time to
convert plpython to untrusted status tomorrow.  I do not have the time,
the infrastructure, nor the interest to build a conditional setup.
Unless someone else wants to volunteer to make it happen in a timely
fashion, untrusted is what it will be.

			regards, tom lane

Sun, 29 Jun 2003 23:39:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PlPython 
Hannu Krosing wrote:
> could we not just make sure that plpython uses python ver < 2.x and use
> plpythonu for python versions >= 2.x until a secure regex solution comes
> from Guido and folks ?
> 
> I guess most plpython users would be much happier with plpython with
> some minor limitations due to older version than with being forced to
> use an untrusted pl altogether.

But if rexec isn't safe they're just fooling themselves. There's only 
two kinds of safety for restricted environments: absolute and not. 
That's why the Python developers were honest and disabled rexec for now.

If you want to fool yourself, that's easy enough: ship a modified 
rexec.py with the 'raise RuntimeError, "This code is not secure ..."' 
removed ;-)

> IIRC python 1.5.2 has a perfectly good RExec.

You are likely mistaken. Because I was interested in getting this 
problem solved for plpython and because most rexec problems are because 
of the new-style classes in Python 2.2 and later, I asked on 
comp.lang.python wether it was safe with 2.1 and earlier.

Martin von Lï¿½wis told me it probably wasn't in 
http://groups.google.com/groups?selm=m3y8ztib79.fsf%40mira.informatik.hu-berlin.de

> Or is there a requirement that only latest language versions are used in
> pg 74 ;)

No, but I find it hard to believe that PL/python is used by untrusted 
users at all, so making it untrusted might not really be a problem in 
real life.

-- Gerhard

PS: Thanks Kevin for submitting the PL/Python patch. I intended to make 
it available at least as an untrusted language, but you beat me :)

Mon, 30 Jun 2003 06:39:30 +0200
=?ISO-8859-1?Q?Gerhard_H=E4ring?= <gh@ghaering.de>
Re: PlPython
=?ISO-8859-1?Q?Gerhard_H=E4ring?= <gh@ghaering.de> writes:
> ... because most rexec problems are because 
> of the new-style classes in Python 2.2 and later, I asked on 
> comp.lang.python wether it was safe with 2.1 and earlier.

> Martin von L�wis told me it probably wasn't in 
> http://groups.google.com/groups?selm=m3y8ztib79.fsf%40mira.informatik.hu-berlin.de

Hmm.  I don't think the second bug mentioned there applies to us (if our
use of rexec allows the Python code to write any file anywhere, it's
already lost its right to trusted status IMHO).  But the first one looks
like a killer:
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=577530
According to that discussion, this bug does exist in Python 1.5 :-(
... so Hannu's argument rests on a false premise anyway.

			regards, tom lane

Mon, 30 Jun 2003 01:08:37 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
Tom Lane kirjutas E, 30.06.2003 kell 06:39:
> Hannu Krosing <hannu@tm.ee> writes:
> > Tom Lane kirjutas E, 30.06.2003 kell 01:21:
> >> Who's still using 1.5, I guess is the question?  And are they likely
> >> to be updating their PG installation when they're not updating Python?
> 
> > I guess that anyone who needs safe Restricted Execution will be using
> > 1.5 at least for that purpose until RExec is fixed in 2.x.
> 
> I don't find that real compelling ...
> 
> The bottom line is that this has to get done.  I have the time to
> convert plpython to untrusted status tomorrow.  I do not have the time,
> the infrastructure, nor the interest to build a conditional setup.
> Unless someone else wants to volunteer to make it happen in a timely
> fashion, untrusted is what it will be.

Fine with me.

Just don't put in any hacks to pretend it is trusted.

---------------
Hannu



30 Jun 2003 10:30:47 +0300
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] PlPython
Gerhard Häring kirjutas E, 30.06.2003 kell 07:39:
> Hannu Krosing wrote:

> > IIRC python 1.5.2 has a perfectly good RExec.
> 
> You are likely mistaken. Because I was interested in getting this 
> problem solved for plpython and because most rexec problems are because 
> of the new-style classes in Python 2.2 and later, I asked on 
> comp.lang.python wether it was safe with 2.1 and earlier.
> 
> Martin von Löwis told me it probably wasn't in 
> http://groups.google.com/groups?selm=m3y8ztib79.fsf%40mira.informatik.hu-berlin.de

Uups! I got that impression from the emails which claimed that new-style
classes make it near impossilble to fix.

> > Or is there a requirement that only latest language versions are used in
> > pg 74 ;)
> 
> No, but I find it hard to believe that PL/python is used by untrusted 
> users at all, so making it untrusted might not really be a problem in 
> real life.

That is most likely true.

And trusted users like to use untrusted languages, so they can send
email, get xml via http and write files ;)

-------------
Hannu


30 Jun 2003 10:48:02 +0300
Hannu Krosing <hannu@tm.ee>
Re: PlPython
Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> Attached is a patch that removes all of the RExec code from plpython from
> the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
> untrusted language in createlang.

I'm working on the latter and cleaning up the documentation.  How does
your patch affect this statement in the plpython documentation?

   Each function gets its own restricted execution object in the
   Python interpreter, so that global data and function arguments from
   <function>myfunc</function> are not available to
   <function>myfunc2</function>.  The exception is the data in the
   <varname>GD</varname> dictionary, as mentioned above.

			regards, tom lane

Mon, 30 Jun 2003 14:11:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
On Mon, 30 Jun 2003, Tom Lane wrote:
> Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> > Attached is a patch that removes all of the RExec code from plpython from
> > the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
> > untrusted language in createlang.
> 
> I'm working on the latter and cleaning up the documentation.  How does
> your patch affect this statement in the plpython documentation?
> 
>    Each function gets its own restricted execution object in the
>    Python interpreter, so that global data and function arguments from
>    <function>myfunc</function> are not available to
>    <function>myfunc2</function>.  The exception is the data in the
>    <varname>GD</varname> dictionary, as mentioned above.

Only a slight modification is needed:

  Each function gets its own execution enviornment in the 
  Python interpreter, ...

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com


Mon, 30 Jun 2003 15:02:06 -0400 (EDT)
Kevin Jacobs <jacobs@penguin.theopalgroup.com>
Re: PlPython 
Hannu Krosing writes:
> Tom Lane kirjutas E, 23.06.2003 kell 01:29:
> > Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> > > Attached is a patch that removes all of the RExec code from plpython
> > > from the current PostgreSQL CVS.  In addition, plpython needs to be
> > > changed to an untrusted language in createlang.
> >
> > I am inclined to rename plpython to plpythonu, by analogy to pltclu.
>
> ...
>
> > Comments?
>
> could we not just make sure that plpython uses python ver < 2.x and use
> plpythonu for python versions >= 2.x until a secure regex solution comes
> from Guido and folks ?
>
> I guess most plpython users would be much happier with plpython with
> some minor limitations due to older version than with being forced to
> use an untrusted pl altogether.

Actually, there are also people (me, for example :-), who would love to see an 
untrusted PlPython to use the full Python power as Pl. So I'd be very happy 
with a solution, where I could choose between plpython and plpythonu. But I 
don't know if that means having twice the effort compared to only having 
plpython _or_ plpythonu.

Regards,

	Tilo



Mon, 30 Jun 2003 22:28:56 +0200
Tilo Schwarz <mail@tilo-schwarz.de>
Re: PlPython

According to my testing that statement about dictionaries
is still valid.

Did you see my other note about which imports
were allowed?  

I have only been able to do a tiny bit  of further
testing and found that my test for zlib was wrong, it does
load and my test for module mpz was
inconclusive--there is some unidentified symbol. 

I am only sure that codecs kicks out
as an untrusted module.

ERROR:  plpython: Call of function `__plpython_procedure_import_test_1849240' failed.
exceptions.SystemError: Failed to load the builtin codecs: untrusted dynamic module: _codecs

I don't think this is a bug until we decide how it is supposed to work
but the documentation text does say that the whole set is
not supposed to work so that must change somehow.  

elein

>Just for general knowledge, with python 2.1.1, I was able to 
>import the following documented as "forbidden" modules.
>I have only used "string" so I do NOT assume that enabling
>import means that they all work.  (more testing...)

>        array bisect binascii calendar cmath errno
>        marshal math md5 operator pcre pickle
>        random re regex sha StringIO struct
>        time whrandom string
>
>The following modules from the forbidden
>list caused import errors as expected:
>        zlib, codecs, mpz


On Monday 30 June 2003 11:11, Tom Lane wrote:
> Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> > Attached is a patch that removes all of the RExec code from plpython from
> > the current PostgreSQL CVS.  In addition, plpython needs to be changed to an
> > untrusted language in createlang.
> 
> I'm working on the latter and cleaning up the documentation.  How does
> your patch affect this statement in the plpython documentation?
> 
>    Each function gets its own restricted execution object in the
>    Python interpreter, so that global data and function arguments from
>    <function>myfunc</function> are not available to
>    <function>myfunc2</function>.  The exception is the data in the
>    <varname>GD</varname> dictionary, as mentioned above.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 
> 

-- 
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


Mon, 30 Jun 2003 13:34:34 -0700
elein <elein@varlena.com>
Re: PlPython
elein  <elein@varlena.com> writes:
> According to my testing that statement about dictionaries
> is still valid.

What are you testing?  It sure looks like it's not the untrusted version
of plpython:

> ERROR:  plpython: Call of function `__plpython_procedure_import_test_1849240' failed.
> exceptions.SystemError: Failed to load the builtin codecs: untrusted dynamic module: _codecs

AFAIK that "untrusted dynamic module" error is from RExec.

			regards, tom lane

Mon, 30 Jun 2003 16:45:50 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 

(@***@*#$*(@#&&)

Checking on the build that was supposed to install
the patch, I now see I have an incorrect conf argument.
Take 2.  I'll rerun these tests right now with a good build.
Give me 1/2 hour max.

--elein


On Monday 30 June 2003 13:45, Tom Lane wrote:
> elein  <elein@varlena.com> writes:
> > According to my testing that statement about dictionaries
> > is still valid.
> 
> What are you testing?  It sure looks like it's not the untrusted version
> of plpython:
> 
> > ERROR:  plpython: Call of function `__plpython_procedure_import_test_1849240' failed.
> > exceptions.SystemError: Failed to load the builtin codecs: untrusted dynamic module: _codecs
> 
> AFAIK that "untrusted dynamic module" error is from RExec.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
>                http://archives.postgresql.org
> 
> 

-- 
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


Mon, 30 Jun 2003 13:58:27 -0700
elein <elein@varlena.com>
Re: PlPython


OK.  SD and GD behaviours are valid as stated in the
original docs.  I assume, therefore, that TD (for triggers)
also behaves.

All of the "forbidded" imports work with the following
exceptions:
	* mpz -- undefined symbol -- probably just my system
	* some modules are dependent on others so
	you may have to order them correctly.  This is
	just I python thing I think.

I was testing on SuSe 7.3 with Kevin's patch applied to
PostgreSQL v7.3.2.

Sorry about the mixup earlier.  But the "forbidden" 
modules part still needs to be tossed for the new 
doc.

elein

On Monday 30 June 2003 13:58, elein wrote:
> (@***@*#$*(@#&&)
> 
> Checking on the build that was supposed to install
> the patch, I now see I have an incorrect conf argument.
> Take 2.  I'll rerun these tests right now with a good build.
> Give me 1/2 hour max.
> 
> --elein
> 
> 
> On Monday 30 June 2003 13:45, Tom Lane wrote:
> > elein  <elein@varlena.com> writes:
> > > According to my testing that statement about dictionaries
> > > is still valid.
> > 
> > What are you testing?  It sure looks like it's not the untrusted version
> > of plpython:
> > 
> > > ERROR:  plpython: Call of function `__plpython_procedure_import_test_1849240' failed.
> > > exceptions.SystemError: Failed to load the builtin codecs: untrusted dynamic module: _codecs
> > 
> > AFAIK that "untrusted dynamic module" error is from RExec.
> > 
> > 			regards, tom lane
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> > 
> >                http://archives.postgresql.org
> > 
> > 
> 
> -- 
> =============================================================
> elein@varlena.com     Database Consulting     www.varlena.com
> PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
>    "Free your mind the rest will follow" -- en vogue
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 
> 

-- 
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


Mon, 30 Jun 2003 14:11:57 -0700
elein <elein@varlena.com>
Re: PlPython

That the imports "work" means that you *can*
import them.  That does not mean I tested
their functionality (except for string).

elein

On Monday 30 June 2003 14:11, elein wrote:
> OK.  SD and GD behaviours are valid as stated in the
> original docs.  I assume, therefore, that TD (for triggers)
> also behaves.
> 
> All of the "forbidded" imports work with the following
> exceptions:
> 	* mpz -- undefined symbol -- probably just my system
> 	* some modules are dependent on others so
> 	you may have to order them correctly.  This is
> 	just I python thing I think.
> 
> I was testing on SuSe 7.3 with Kevin's patch applied to
> PostgreSQL v7.3.2.
> 
> Sorry about the mixup earlier.  But the "forbidden" 
> modules part still needs to be tossed for the new 
> doc.
> 
> elein
> 
> On Monday 30 June 2003 13:58, elein wrote:
> > (@***@*#$*(@#&&)
> > 
> > Checking on the build that was supposed to install
> > the patch, I now see I have an incorrect conf argument.
> > Take 2.  I'll rerun these tests right now with a good build.
> > Give me 1/2 hour max.
> > 
> > --elein
> > 
> > 
> > On Monday 30 June 2003 13:45, Tom Lane wrote:
> > > elein  <elein@varlena.com> writes:
> > > > According to my testing that statement about dictionaries
> > > > is still valid.
> > > 
> > > What are you testing?  It sure looks like it's not the untrusted version
> > > of plpython:
> > > 
> > > > ERROR:  plpython: Call of function `__plpython_procedure_import_test_1849240' failed.
> > > > exceptions.SystemError: Failed to load the builtin codecs: untrusted dynamic module: _codecs
> > > 
> > > AFAIK that "untrusted dynamic module" error is from RExec.
> > > 
> > > 			regards, tom lane
> > > 
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 6: Have you searched our list archives?
> > > 
> > >                http://archives.postgresql.org
> > > 
> > > 
> > 
> > -- 
> > =============================================================
> > elein@varlena.com     Database Consulting     www.varlena.com
> > PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
> >    "Free your mind the rest will follow" -- en vogue
> > 
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> > 
> > 
> 
> -- 
> =============================================================
> elein@varlena.com     Database Consulting     www.varlena.com
> PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
>    "Free your mind the rest will follow" -- en vogue
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faqs/FAQ.html
> 
> 

-- 
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


Mon, 30 Jun 2003 14:14:09 -0700
elein <elein@varlena.com>
Re: PlPython
elein  <elein@varlena.com> writes:
> Sorry about the mixup earlier.  But the "forbidden" 
> modules part still needs to be tossed for the new doc.

Right.  I already pulled section 43.4 --- see the updated docs at
http://developer.postgresql.org/docs/postgres/plpython.html

I've also commented out the paragraph about global data and function
arguments pending resolution of the question.  Given the reference to
restricted execution objects in the original text, I would think that
the removal of rexec usage means that plpython functions can now get at
any global data.  But I'm not a Python user and might be
misunderstanding the point.

			regards, tom lane

Mon, 30 Jun 2003 17:32:18 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
On Mon, 30 Jun 2003, Tom Lane wrote:
> elein  <elein@varlena.com> writes:
> > Sorry about the mixup earlier.  But the "forbidden" 
> > modules part still needs to be tossed for the new doc.
> 
> Right.  I already pulled section 43.4 --- see the updated docs at
> http://developer.postgresql.org/docs/postgres/plpython.html
> 
> I've also commented out the paragraph about global data and function
> arguments pending resolution of the question.  Given the reference to
> restricted execution objects in the original text, I would think that
> the removal of rexec usage means that plpython functions can now get at
> any global data.  But I'm not a Python user and might be
> misunderstanding the point.

The scope of each function is still private, so global data are not shared
unless explicitly stored in the "GD" dictionary.  This is still the case
with my updated code.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com


Mon, 30 Jun 2003 17:36:36 -0400 (EDT)
Kevin Jacobs <jacobs@penguin.theopalgroup.com>
Re: PlPython 

The global data (GD) and function data (SD)
work as they always have worked.  That is the
part I was most anxious to test.

GD is sharable between any python functions.
It always was.  It is a memory leak hazard with warnings.

SD is sharable within the same *connection*
only by the same function (name+argtypes).
The scope of SD is kinda weird but is
consistent with its previous behaviour.

(I did rerun those tests on the newly correctly
built versions.)

elein

On Monday 30 June 2003 14:32, Tom Lane wrote:
> elein  <elein@varlena.com> writes:
> > Sorry about the mixup earlier.  But the "forbidden" 
> > modules part still needs to be tossed for the new doc.
> 
> Right.  I already pulled section 43.4 --- see the updated docs at
> http://developer.postgresql.org/docs/postgres/plpython.html
> 
> I've also commented out the paragraph about global data and function
> arguments pending resolution of the question.  Given the reference to
> restricted execution objects in the original text, I would think that
> the removal of rexec usage means that plpython functions can now get at
> any global data.  But I'm not a Python user and might be
> misunderstanding the point.
> 
> 			regards, tom lane
> 
> 

-- 
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


Mon, 30 Jun 2003 14:44:23 -0700
elein <elein@varlena.com>
Re: PlPython
elein  <elein@varlena.com> writes:
> The global data (GD) and function data (SD)
> work as they always have worked.

Right, but the para at issue was claiming you couldn't access any global
data *except* GD.

			regards, tom lane

Mon, 30 Jun 2003 17:49:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 

7.3 doc says:

>The global dictionary SD is available to store data between function calls. This variable is private static data. 
>The global dictionary GD is public data, available to all Python functions within a session. Use with care.>

>Each function gets its own restricted execution object in the Python interpreter, so that global data and >
>function arguments from myfunc are not available to myfunc2. 
>The exception is the data in the GD dictionary, as mentioned above.

I think the above is correct, and the terms I used could be confusing.  The doc
is calling both GD and SD global data.  These are distinct from the function arguments.
Function arguments are distinct to the invocation of the function.
You can get to GD elements from any called plpython function.  You can get to SD elements
only from (re-)calling the same plpython function.

How about changing the second paragraph to:

   Each function gets its own restricted execution object in the Python interpreter so that SD global
   data and function arguments from myfunc are not available to myfunc2.  Data stored in the
   GD dictionary by myfunc may be accessed by myfunc2.


More than you wanted to know, I'm sure.

elein


On Monday 30 June 2003 14:49, Tom Lane wrote:
> elein  <elein@varlena.com> writes:
> > The global data (GD) and function data (SD)
> > work as they always have worked.
> 
> Right, but the para at issue was claiming you couldn't access any global
> data *except* GD.
> 
> 			regards, tom lane
> 
> 

-- 
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


Mon, 30 Jun 2003 14:59:30 -0700
elein <elein@varlena.com>
Re: PlPython
elein kirjutas T, 24.06.2003 kell 00:42:

There is a realtively clean hack one can use to convert plpython
functions to plpythonu manually - just rename the language for the time
of loading functions - do as superuser

update pg_language set lanname = 'plpython' where lanname = 'plpythonu';

LOAD YOUR Pl/Python FUNCTIONS ;

update pg_language set lanname = 'plpythonu' where lanname = 'plpython';

> PS: I've built and tested the plpython patch against
> 7.3.2 and am happy it does not affect the features I count
> on. 

As it should.

The untrusted language gives you *more* power, not less.

The untrusted status means that the user has to be trusted to use that
much power.

----------------
Hannu

01 Jul 2003 10:23:58 +0300
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] PlPython
Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> On Mon, 30 Jun 2003, Tom Lane wrote:
>> I've also commented out the paragraph about global data and function
>> arguments pending resolution of the question.  Given the reference to
>> restricted execution objects in the original text, I would think that
>> the removal of rexec usage means that plpython functions can now get at
>> any global data.  But I'm not a Python user and might be
>> misunderstanding the point.

> The scope of each function is still private, so global data are not shared
> unless explicitly stored in the "GD" dictionary.  This is still the case
> with my updated code.

Okay, but surely the reference to restricted execution objects is now
wrong?  Can you give me corrected text for the para in question?

   Each function gets its own restricted execution object in the
   Python interpreter, so that global data and function arguments from
   <function>myfunc</function> are not available to
   <function>myfunc2</function>.  The exception is the data in the
   <varname>GD</varname> dictionary, as mentioned above.

			regards, tom lane

Tue, 01 Jul 2003 09:46:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> Only a slight modification is needed:

>   Each function gets its own execution enviornment in the 
>   Python interpreter, ...

Got it, thanks.  (For some reason this message seems to have been
delayed.)

			regards, tom lane

Tue, 01 Jul 2003 09:53:30 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PlPython 
elein wrote:
> Yes, I understand.  (And the dev docs look pretty darn good)
> 
> I was just  wondering if postgresql had a language independent
> definitive list of  "dangerous" functionality, but it seems
> that the trusted-ness implementation is pretty language specific.

The most language-independant definition would be:

     If the language doesn't allow access to objects, the function
     creator doesn't have access to through regular SQL, then it
     can be trusted.

Trusted just means, you can allow any ordinary user to write funcitons 
in that language and he'll not gain any additional access rights through 
doing so.


Jan

> 
> Just for general knowledge, with python 2.1.1, I was able to 
> import the following documented as "forbidden" modules.
> I have only used "string" so I do NOT assume that enabling
> import means that they all work.  (more testing...)
> 
> 	array bisect binascii calendar cmath errno
> 	marshal math md5 operator pcre pickle
> 	random re regex sha StringIO struct
> 	time whrandom string
> 
> The following modules from the forbidden
> list caused import errors as expected:
> 	zlib, codecs, mpz
> 
> I'll do some more testing and submit a more complete
> doc patch if I can squeeze in the time.  Or if someone
> else wants to help let me know.
> 
> elein@varlena.com
> 
> On Friday 27 June 2003 15:15, scott.marlowe wrote:
>> C is god.  I.e. C functions run as the same user as the postmaster, and 
>> can do anything they want, and it takes a superuser to install functions 
>> written in it.
>> 
>> The following are (were...?) trusted languages in 7.3.3:
>> 
>> plpgsql
>> pltcl
>> plpython
>> plsql (built in)
>> 
>> These are the untrusted languages in 7.3.3:
>> 
>> pltclu
>> plperlu
>> C functions
>> 
>> A trusted language is basically one that lives in a box that won't let it 
>> do dangerous things like write files, call system calls as the postgres 
>> super user etc...
>> 
>> Explanation (still in need of editing for the final release of 7.4) are 
>> here:
>> 
>> http://developer.postgresql.org/docs/postgres/xplang.html 
>> 
>> On Fri, 27 Jun 2003, elein wrote:
>> 
>> > 
>> > 
>> > Perhaps this should be asked on the interfaces list, but...
>> > Exactly what functions are prohibited (or acceptable)
>> > for a pl language in PostgreSQL to become trusted?
>> > 
>> > Is the exact criteria list documented somewhere?
>> > 
>> > Since C is wide open, why is it considered trusted,
>> > or is it?  Or are some C calls disallowed by the
>> > function manager (this was what we did at informix,
>> > we also enforced permissions carefully (after showing
>> > how easy it was to break things :-) ).
>> > 
>> > My guess of the list would be:
>> > 	1. No or a restricted set of OS calls 
>> > 		(what would be the restricted set?
>> > 		 The set Keith removed?)
>> > 	2. No file system operations or strongly
>> > 	   enforced permissions on file system operations.
>> > 
>> > Elein
>> > 
>> > On Thursday 26 June 2003 11:48, Karsten Hilbert wrote:
>> > > >>Now that the rexec code is gone, it MUST be marked untrusted --- this is
>> > > >>not a question for debate.  Installing it as trusted would be a security
>> > > >>hole.
>> > > > 
>> > > > That means that there is something else untrusted in PLPython,
>> > > > what is this?
>> > > Well, basically everything else.
>> > > 
>> > > You are getting this backwards. Making Python a *trusted*
>> > > language *requires* something like rexec. Since we don't have
>> > > rexec anymore (it never was much good, apparently) we cannot
>> > > make Python trusted. Hence we must make it untrusted to keep
>> > > it in at all.
>> > > 
>> > > The point here is not whether we trust the rest of Python but
>> > > whether we have something (like rexec) that restricts the
>> > > standard Python. Only if we have that do we define a language
>> > > as "trusted".
>> > > 
>> > > Things would be different, of course, if an entire language
>> > > was restricted by nature. That would be a candidate for a
>> > > trusted language without needing specific add-on execution
>> > > restriction.
>> > > 
>> > > Karsten
>> > > -- 
>> > > GPG key ID E4071346 @ wwwkeys.pgp.net
>> > > E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>> > > 
>> > > ---------------------------(end of broadcast)---------------------------
>> > > TIP 2: you can get off all lists at once with the unregister command
>> > >     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>> > > 
>> > > 
>> > 
>> > 
>> 
>> 
> 



-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Wed, 09 Jul 2003 11:55:18 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: PlPython