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
