| From: | Peter Eisentraut <peter_e(at)gmx(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:22:01 |
| Message-ID: | 1275049321.6851.1.camel@fsopti579.F-Secure.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On fre, 2010-05-28 at 13:03 +0100, Sam Mason wrote:
> 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.
Surely a definition of a trusted language that invalidates the existing
trusted languages is not going help resolve the issue.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2010-05-28 12:24:54 | Re: Specification for Trusted PLs? |
| Previous Message | Sam Mason | 2010-05-28 12:03:11 | Re: Specification for Trusted PLs? |