On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote:
> Robert Haas <robertmh...@gmail.com> writes:
> > On Fri, May 21, 2010 at 2:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> (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.
> 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.

David (who is not, at this point, going to suggest that a "trusted"
boolean may inadequately reflect users' needs)
David Fetter <da...@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to