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

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

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.

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

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

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

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

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

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

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

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

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

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:

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:

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

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

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)               |
+-----------------------------------------------------------

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

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