On Thu, May 27, 2010 at 7:10 PM, David Fetter <da...@fetter.org> wrote: > On Fri, May 28, 2010 at 01:03:15AM +0300, Peter Eisentraut wrote: >> On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote: >> > On Fri, May 21, 2010 at 2:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> > > Robert Haas <robertmh...@gmail.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? >> > >> > Doesn't subvert the general PostgreSQL security mechanisms? Not >> > sure how to formulate that. >> >> Succinctly: A trusted language does not grant access to data that >> the user would otherwise not have. > > That's a great definition from a point of view of understanding by > human beings. A whitelist system will work better from the point of > automating tests which, while they couldn't conclusively prove that > something was actually this way, could go a long way toward making > sure that PLs didn't regress into untrusted territory.
You haven't presented any sort of plan for how such automated testing would actually work. Perhaps if you presented the plan first we could think about how to provide for its needs. I'm generally of the opinion that it's not possible to do automated testing for security vulnerabilities (beyond crash testing, perhaps) but if you have a good idea let's talk about it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
