On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Fri, May 21, 2010 at 2:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
David (who is not, at this point, going to suggest that a "trusted"
boolean may inadequately reflect users' needs)
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
In response to
pgsql-hackers by date
|Next:||From: David Fetter||Date: 2010-05-21 19:40:17|
|Subject: Re: Specification for Trusted PLs?|
|Previous:||From: Tom Lane||Date: 2010-05-21 19:24:35|
|Subject: Re: small exclusion constraints patch |