From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: allow building trusted languages without the untrusted versions
In-reply-to: <20220523165403.GC938919@nathanxps13>
References: <20220520225619.GA876272@nathanxps13>
 <571753.1653092411@sss.pgh.pa.us> <20220523165403.GC938919@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Mon, 23 May 2022 09:54:03 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1290328.1653326228.1@sss.pgh.pa.us>
Date: Mon, 23 May 2022 13:17:08 -0400
Message-ID: <1290329.1653326228@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1290329.1653326228%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Fri, May 20, 2022 at 08:20:11PM -0400, Tom Lane wrote:
>> Lastly, you've offered no reason to think this would provide any real
>> security improvement.  Someone who's gained the ability to issue CREATE
>> EXTENSION on untrusted extensions has already got all the privileges he
>> needs; leaving out a few extension files is at most going to slow him
>> down a bit on the way to full filesystem access.  (See, eg, COPY TO
>> PROGRAM.)

> I'd like to provide the ability to disallow these other things, too.  This
> is intended to be a first step in that direction.

There would probably be some interest in a "--disable-disk-access"
configure option that did all of this stuff (and some more things
too), with the aim of locking down *all* known paths to filesystem
access.  I don't see much value in retail options that do some of that.
In fact, what they might mostly accomplish is to give people a false
sense of security.

			regards, tom lane