From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Specification for Trusted PLs? |
Date: | 2010-05-28 12:24:54 |
Message-ID: | 4BFFB616.9040002@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sam Mason wrote:
> On Thu, May 27, 2010 at 11:09:26PM -0400, Tom Lane wrote:
>
>> David Fetter <david(at)fetter(dot)org> writes:
>>
>>> I don't know about a *good* idea, but here's the one I've got.
>>>
>>> 1. Make a whitelist. This is what needs to work in order for a
>>> language to be a fully functional trusted PL.
>>>
>> Well, I pretty much lose interest right here, because this is already
>> assuming that every potentially trusted PL is isomorphic in its
>> capabilities.
>>
>
> That's not normally a problem. The conventional way would be to place
> the interpreter in its own sandbox, similar to how Chrome has each tab
> running in its own process. These processes are protected in a way
> so that the code running inside them can't do any harm--e.g. a ptrace
> jail[1]. This is quite a change from existing pl implementations, and
> present a different set of performance/compatibility issues.
>
>
I have my own translation of this last sentence.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-05-28 13:11:02 | Re: Failback with log shipping |
Previous Message | Peter Eisentraut | 2010-05-28 12:22:01 | Re: Specification for Trusted PLs? |