Re: allow building trusted languages without the untrusted versions

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: allow building trusted languages without the untrusted versions
Date: 2022-05-23 16:54:03
Message-ID: 20220523165403.GC938919@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 20, 2022 at 08:20:11PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-05-23 17:17:08 Re: allow building trusted languages without the untrusted versions
Previous Message Nathan Bossart 2022-05-23 16:41:42 Re: docs: mention "pg_read_all_stats" in "track_activities" description