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 #