Re: Specification for Trusted PLs?

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-24 01:16:48
Message-ID: 4BF9D380.2040201@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/23/2010 6:14 PM, Ron Mayer wrote:
> Tom Lane 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)
>
> If a PL has file access to it's own sandbox (similar to what
> flash seems to do in web browsers), could that be considered
> trusted?

That is a good question.

Currently, the first of all TRUSTED languages, PL/Tcl, would allow the
function of a lesser privileged user access the "global" objects of
every other database user created within the same session.

These are per backend in memory objects, but none the less, an evil
function could just scan the per backend Tcl namespace and look for
compromising data, and that's not exactly what TRUSTED is all about.

In the case of Tcl it is possible to create a separate "safe"
interpreter per DB role to fix this. I actually think this would be the
right thing to do.

Jan

--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2010-05-24 01:18:39 Re: Exposing the Xact commit order to the user
Previous Message Robert Haas 2010-05-24 00:38:14 Re: Exposing the Xact commit order to the user