Date: Mon, 23 May 2022 17:04:27 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: allow building trusted languages without the untrusted versions
Message-ID: <20220524000427.GA1186400@nathanxps13>
References: <20220520225619.GA876272@nathanxps13>
 <571753.1653092411@sss.pgh.pa.us>
 <20220523165403.GC938919@nathanxps13>
 <1290329.1653326228@sss.pgh.pa.us>
 <CA+TgmoY-Xy_ObfYVUTSamD8BmW8npaktbr65JtnkW-c1VQobVA@mail.gmail.com>
 <1333860.1653338790@sss.pgh.pa.us>
 <CA+TgmoYZKLxftaZZvj4_-zHQ27CBeUs+KvggyU3qS79-7aQEPA@mail.gmail.com>
 <1354561.1653345768@sss.pgh.pa.us>
 <20220523230903.GP9030@tamriel.snowman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220523230903.GP9030@tamriel.snowman.net>
Archived-At: 
 <https://www.postgresql.org/message-id/20220524000427.GA1186400%40nathanxps13>
Precedence: bulk

On Mon, May 23, 2022 at 07:09:03PM -0400, Stephen Frost wrote:
> Instead, I'd argue that we should be continuing to work in the direction
> of splitting up what can only be done by a superuser today using
> predefined roles and other methods along those lines.  How that lines up
> with this latest ask around untrusted languages is something I'm not
> exactly sure about, but a magic configure option that is
> "--don't-allow-what-AWS-doesn't-want-to-allow" certainly doesn't seem
> like it's going in the right direction (and, no, not every cloud
> provider is going to want the exact same thing when it comes to whatever
> this option is that we're talking about, so we'd end up having to have
> configure options for each if we start going down this road...).

I guess I'd like to do both.  I agree with continuing the work with
predefined roles, etc., but I also think there is value in being able to
compile out things that allow arbitrary disk/network access.  My intent
with this thread is the latter, and I'm trying to tackle this in a way that
is generically useful even beyond the cloud provider use case.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com