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

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

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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Limiting memory allocation
Next
From: Noah Misch
Date:
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set