Re: Specification for Trusted PLs?

From: Jonathan Leto <jonathan(at)leto(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Specification for Trusted PLs?
Date: 2010-05-21 20:08:53
Message-ID: AANLkTintUIVWEi9ZSy7ZhM60GK5svGSuD8wRc7bMIXNG@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Howdy,

On Fri, May 21, 2010 at 11:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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(at)leto(dot)net
http://leto.net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Tolley 2010-05-21 20:21:40 Re: Specification for Trusted PLs?
Previous Message Tom Lane 2010-05-21 20:04:38 Re: Specification for Trusted PLs?