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

From Jonathan S. Katz
Subject Re: allow building trusted languages without the untrusted versions
Date
Msg-id 68738fbe-7c06-ce76-5380-ef88d5bad6df@postgresql.org
Whole thread Raw
In response to Re: allow building trusted languages without the untrusted versions  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: "shiy.fnst@fujitsu.com"
Date:
Subject: RE: Handle infinite recursion in logical replication setup
Next
From: "bucoo"
Date:
Subject: partition wise aggregate wrong rows cost