Re: Specification for Trusted PLs?
Joshua Tolley <eggyknap@gmail.com>
From: Joshua Tolley <eggyknap@gmail.com>
To: David Fetter <david@fetter.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-21T19:55:25Z
Lists: pgsql-hackers
On Fri, May 21, 2010 at 1:36 PM, David Fetter <david@fetter.org> wrote: > On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote: >> As long as you can't do database access except via SPI, that should >> be covered. So I guess the next item on the list is no, or at least >> restricted, access to functions outside the PL's own language. > > "No access" seems pretty draconian. > > How about limiting such access to functions of equal or lower > trustedness? Surely an untrusted function shouldn't be restricted > from calling other untrusted functions based on the language they're > written in. 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 launch_missiles()". -- Joshua Tolley / eggyknap End Point Corporation