Re: Specification for Trusted PLs?

Jonathan Leto <jonathan@leto.net>

From: Jonathan Leto <jonathan@leto.net>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Robert Haas <robertmhaas@gmail.com>, David Fetter <david@fetter.org>, Stephen Frost <sfrost@snowman.net>, Magnus Hagander <magnus@hagander.net>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2010-05-21T20:08:53Z

Lists: pgsql-hackers

Howdy,

On Fri, May 21, 2010 at 11:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> So... can we get back to coming up with a reasonable
>> definition,
>
> (1) no access to system calls (including file and network I/O)
>
> (2) no access to process memory, other than variables defined within the
> PL.
>
> What else?

I ran across this comment in PL/Perl while implementing PL/Parrot, and
I think it should be taken into consideration for the definition of
trusted/untrusted:

/*
 * plperl.on_plperl_init is currently PGC_SUSET to avoid issues whereby a
 * user who doesn't have USAGE privileges on the plperl language could
 * possibly use SET plperl.on_plperl_init='...' to influence the behaviour
 * of any existing plperl function that they can EXECUTE (which may be
 * security definer). Set
 * http://archives.postgresql.org/pgsql-hackers/2010-02/msg00281.php and
 * the overall thread.
 */

Duke

-- 
Jonathan "Duke" Leto
jonathan@leto.net
http://leto.net