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

On Fri, May 20, 2022 at 08:20:11PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> Presently, if you want to only build trusted PL/Perl and PL/Tcl, you need
>> to make a couple of code changes to compile out the untrusted parts.  I
>> suspect many users (e.g., anyone who wants to disallow file system access)
>> would benefit from a better supported way to do this.  Thus, I've attached
>> some patches that introduce an optional argument for the --with-perl and
>> --with-tcl configuration options.  This new argument can be used to build
>> only the trusted or untrusted version of the language.  If the argument is
>> not provided, both the trusted and untrusted versions are built, so this
>> change is backward compatible.
> 
> I do not believe that this is worth the extra complication.  Nobody has
> ever asked for it before, so I estimate the number of people who would
> use it as near zero, and those folk are entirely capable of removing
> the relevant extension files from their installations.

Of course, if there is no interest in this feature, I'll withdraw the patch
from consideration.  However, I will note that moving the extension files
aside is not sufficient for blocking all use of untrusted languages, since
the symbols for their handler/validator functions will still be present.

> Moreover, if we accept this as a useful configure option, what other
> things will we be called on to change?  It surely makes no sense to
> install contrib/adminpack, for instance, if you're afraid of having
> plperlu installed.
> 
> 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.

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