Re: allow building trusted languages without the untrusted versions - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: allow building trusted languages without the untrusted versions
Date
Msg-id 20220523165403.GC938919@nathanxps13
Whole thread Raw
In response to Re: allow building trusted languages without the untrusted versions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: allow building trusted languages without the untrusted versions
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: docs: mention "pg_read_all_stats" in "track_activities" description
Next
From: Tom Lane
Date:
Subject: Re: allow building trusted languages without the untrusted versions