On Thu, May 27, 2010 at 7:10 PM, David Fetter <david@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 <tgl@sss.pgh.pa.us> wrote:
>> > > Robert Haas <robertmhaas@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