Re: allow building trusted languages without the untrusted versions

On Tue, May 24, 2022 at 1:28 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> Can we do both? That is, can we add retail options for untrusted
> languages, generic file access functions, etc., and then also introduce a
> --disable-disk-access configuration option? The latter might even just be
> a combination of retail options. This would allow for more granular
> configurations, but it also could help address Tom's concerns.

Oh, sure. We're in charge around here. We can do whatever we want! The
only trick is agreeing with each other to a sufficient degree to get
something done ... and of course the small matter of writing the code.

I guess one question is at what level we want to disable these various
things. Your original proposal seemed reasonable to me because I feel
like users who are compiling PostgreSQL ought to have control over
which things they compile. If you can turn plperl and plperlu off
together, and you can, then why shouldn't you be able to turn them on
and off separately? I can't think of a good reason why we shouldn't
make that possible if people want it, and evidently at least one
person does: you. I'm even willing to assume that you represent the
interests of some larger group of people. :-)

But it's not evident to me that it's useful to disable everything
specifically at compile time. I have long thought that it's pretty
bizarre that we permit DML on system catalogs even with
allow_system_table_mods=off, and if I were going to provide a way to
lock that down, I would think of doing it via a new GUC, or a
modification to the existing GUC, or something like that, rather than
a compile-time option -- because we might easily discover a problem in
a future release that requires catalog DML to fix, and you wouldn't
want to have to replace the binaries or even bounce the server to do
that.

And similarly, is it really want we want here to categorically disable
all functions that permit file access for all users under all
circumstances? Or do we maybe want that to be something that can be
reconfigured at runtime? Or even just make it a privilege extended to
some users but not others? What about COPY TO/FROM PROGRAM?

Anyway, I'm not desperately opposed to the idea of having a PostgreSQL
mode that locks a whole lotta crap down at configure time, but I bet
it's going to be (1) hard to get agreement that all of the relevant
stuff is actually worth including and (2) kinda inconvenient not to be
able to change any of that behavior without replacing the binaries. I
do agree that there are SOME things where people are going to
explicitly want that stuff to be unchangeable without replacing the
binaries, and that's fine. I'm just not sure that's what people are
going to want in all cases.

--
Robert Haas
EDB: http://www.enterprisedb.com