Skip site navigation (1) Skip section navigation (2)

Re: Specification for Trusted PLs?

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>,Magnus Hagander <magnus(at)hagander(dot)net>,Josh Berkus <josh(at)agliodbs(dot)com>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Specification for Trusted PLs?
Date: 2010-05-21 19:36:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
written in.

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>
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://

Remember to vote!
Consider donating to Postgres:

In response to


pgsql-hackers by date

Next:From: David FetterDate: 2010-05-21 19:40:17
Subject: Re: Specification for Trusted PLs?
Previous:From: Tom LaneDate: 2010-05-21 19:24:35
Subject: Re: small exclusion constraints patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group