Re: allow building trusted languages without the untrusted versions

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