Обсуждение: PlPython
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
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
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:
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.comContent-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)
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) > >> > >> > > > > > > > >
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, 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
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
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) | +-----------------------------------------------------------
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:
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
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
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
>>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
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
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
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) > > > > > >
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
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
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
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
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
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
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
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
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
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
(@***@*#$*(@#&&) 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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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 #