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

On Tue, May 24, 2022 at 02:10:19PM -0400, Robert Haas wrote:
> 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. :-)

:)

FWIW this was my original thinking.  I can choose to build/install
extensions separately, but when it comes to PL/Tcl and PL/Perl, you've
got to build the trusted and untrusted stuff at the same time, and the
untrusted symbols remain even if you remove the control file and
installation scripts.  Of course, this isn't a complete solution for
removing the ability to do any sort of random file system access, though.

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

Yeah, for certain things, a GUC probably makes more sense.

> 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?

I guess I'd ask again whether we can do both...  We've got predefined roles
like pg_execute_server_program that allow access to COPY TO/FROM PROGRAM,
but I have no way to categorically disable that ѕort of thing if I wanted
to really lock things down, even for superusers.  I'm not suggesting that
every predefined role needs a corresponding configure option, but basic
things like arbitrary disk/network/program access seem like reasonable
proposals.

I have about 50% of a generic --disable-disk-access patch coded up which
I'll share soon to help inform the discussion.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com