From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: allow building trusted languages without the untrusted versions
Date: Tue, 24 May 2022 13:58:41 -0700
Message-ID: <20220524205841.GA1254661@nathanxps13> (raw)
In-Reply-To: <CA+TgmobOQiDXpYq6TgaCzH3p5c0Fko-wXqCjgd5YsR6RsX31vA@mail.gmail.com>
References: <571753.1653092411@sss.pgh.pa.us>
<20220523165403.GC938919@nathanxps13>
<1290329.1653326228@sss.pgh.pa.us>
<CA+TgmoY-Xy_ObfYVUTSamD8BmW8npaktbr65JtnkW-c1VQobVA@mail.gmail.com>
<1333860.1653338790@sss.pgh.pa.us>
<CA+TgmoYZKLxftaZZvj4_-zHQ27CBeUs+KvggyU3qS79-7aQEPA@mail.gmail.com>
<1354561.1653345768@sss.pgh.pa.us>
<CA+TgmoZ_c0j4ut87_QCFm697Qq5Z_u66VZt2PYenfZVjUT1qRA@mail.gmail.com>
<20220524172851.GA1191690@nathanxps13>
<CA+TgmobOQiDXpYq6TgaCzH3p5c0Fko-wXqCjgd5YsR6RsX31vA@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us
Subject: Re: allow building trusted languages without the untrusted versions
In-Reply-To: <20220524205841.GA1254661@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox