| From: | James William Pye <pgsql(at)jwp(dot)name> |
|---|---|
| To: | Tino Wildenhain <tino(at)wildenhain(dot)de>, James Robinson <jlrobins(at)socialserve(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Hackers Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Pl/Python -- current maintainer? |
| Date: | 2006-02-26 01:53:35 |
| Message-ID: | 20060226015335.GA53540@lit.jwp.name |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Feb 25, 2006 at 01:21:34PM -0700, I wrote:
> From what I have seen of zope's restricted python, it does, or can, force its
> restrictions by checking bytecode. I imagine a simple PL sitting on top of the
> untrusted varient that merely implements a custom validator that checks the
> bytecode produced by the untrusted PL's validator. The language handler would
> remain the same:
[ugh, Correcting my assumptions...]
Zope's RestrictedPython is a custom bytecode generator that compiles Python
code specially, as opposed to a bytecode processor that validates against some
rule set as I had thought for some (wishful? ;) reason. The bytecode then needs
to be executed in an special environment that then imposes some specified
restrictions at runtime(I'm not really clear on all the details here as I
am having a very difficult time finding documentation).
This doesn't mean that it couldn't be used. However, it does mean that some
munging of the handler would be required(Something that I desired to avoid).
--
Regards, James William Pye
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Conway | 2006-02-26 02:39:34 | TOAST compression |
| Previous Message | James William Pye | 2006-02-25 22:47:16 | Re: Pl/Python -- current maintainer? |