Re: allow building trusted languages without the untrusted versions

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

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.

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.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2022-05-21 01:28:01 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Previous Message Tomas Vondra 2022-05-20 23:08:49 Re: Limiting memory allocation