On Fri, May 20, 2022 at 08:20:11PM -0400, Tom Lane wrote: > Nathan Bossart <nathandboss...@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