From: Jonathan S. Katz <jkatz@postgresql.org>
To: Nathan Bossart <nathandbossart@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: allow building trusted languages without the untrusted versions
Date: Mon, 23 May 2022 22:49:42 -0400
Message-ID: <68738fbe-7c06-ce76-5380-ef88d5bad6df@postgresql.org> (raw)
In-Reply-To: <20220524000427.GA1186400@nathanxps13>
References: <20220520225619.GA876272@nathanxps13>
<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>
<20220523230903.GP9030@tamriel.snowman.net>
<20220524000427.GA1186400@nathanxps13>
On 5/23/22 8:04 PM, Nathan Bossart wrote:
> On Mon, May 23, 2022 at 07:09:03PM -0400, Stephen Frost wrote:
>> Instead, I'd argue that we should be continuing to work in the direction
>> of splitting up what can only be done by a superuser today using
>> predefined roles and other methods along those lines. How that lines up
>> with this latest ask around untrusted languages is something I'm not
>> exactly sure about, but a magic configure option that is
>> "--don't-allow-what-AWS-doesn't-want-to-allow" certainly doesn't seem
>> like it's going in the right direction (and, no, not every cloud
>> provider is going to want the exact same thing when it comes to whatever
>> this option is that we're talking about, so we'd end up having to have
>> configure options for each if we start going down this road...).
>
> I guess I'd like to do both. I agree with continuing the work with
> predefined roles, etc., but I also think there is value in being able to
> compile out things that allow arbitrary disk/network access. My intent
> with this thread is the latter, and I'm trying to tackle this in a way that
> is generically useful even beyond the cloud provider use case.
(+1 on continuing to split up superuser into other predefined roles and
other privs)
For other use cases, I suggest considering PostgreSQL deployments in
environments that run on restricted filesystems, e.g. containers. When
configured properly, a containerized filesystem will disallow writes
outside of the data directory. However, a) they typically only restrict
writes (which is often good enough) and b) this model holds so long as
there are no exploits in the container itself.
The latter may not be our problem, but we can provide an additional risk
mitigation for folks who deploy PostgreSQL in containers or other
restricted environments the option to compile out features that do allow
arbitrary disk access.
I agree with a bunch of the upthread sentiment, but I would ask if the
current proposal provides acceptable risk mitigation for PostgreSQL
deployments who want to restrict users having access to the filesystem?
Jonathan
Attachments:
[application/pgp-signature] OpenPGP_signature (839B, ../68738fbe-7c06-ce76-5380-ef88d5bad6df@postgresql.org/2-OpenPGP_signature)
download
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: jkatz@postgresql.org, nathandbossart@gmail.com, sfrost@snowman.net, tgl@sss.pgh.pa.us, robertmhaas@gmail.com
Subject: Re: allow building trusted languages without the untrusted versions
In-Reply-To: <68738fbe-7c06-ce76-5380-ef88d5bad6df@postgresql.org>
* 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