Re: Specification for Trusted PLs?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Joshua Tolley <eggyknap@gmail.com>
Cc: David Fetter <david@fetter.org>, Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Magnus Hagander <magnus@hagander.net>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2010-05-21T20:04:38Z
Lists: pgsql-hackers
Joshua Tolley <eggyknap@gmail.com> writes: > Agreed. As long as a trusted language can do things outside the > database only by going through a database and calling some function to > which the user has rights, in an untrusted language, that seems decent > to me. A user with permissions to launch_missiles() would have a > function in an untrusted language to do it, but there's no reason an > untrusted language shouldn't be able to say "SELECT s/untrusted/trusted/ here, right? > launch_missiles()". To me, as long as they go back into the database via SPI, anything they can get to from there is OK. What I meant to highlight upthread is that we don't want trusted functions being able to access other functions "directly" without going through SQL. As an example, a PL that has FFI capability sufficient to allow direct access to heap_insert() would have to be considered untrusted. regards, tom lane