Re: allow building trusted languages without the untrusted versions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allow building trusted languages without the untrusted versions
Date: 2022-05-25 18:28:31
Message-ID: 1978948.1653503311@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> I really don't think this is going to be anywhere near as
> straight-forward as it might appear to be to prevent a superuser from
> being able to break out of PG.

This gets back to the point I made before about it not being worthwhile
to implement half-measures. There is a whole lot of history and code
details associated with the presumption that superuser gives you OS
access, and I'm certainly prepared to believe that turning that off
is a fool's errand.

Perhaps a better answer for providers who need something like this
is to sandbox the Postgres server using OS-provided facilities.

> Instead, we should be moving in the
> direction of making it so that there doesn't need to be a superuser
> that's ever logged into except under serious emergency situations where
> the system is built to require multi-person access to do so.

I'm a little skeptical that our present design direction really moves
the needle very far in this area. We've sliced and diced superuser
aplenty, but that doesn't make individual capabilities such as
pg_write_all_data or ALTER SYSTEM any less dangerous from the standpoint
of someone trying to prevent breaking out.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2022-05-25 20:07:17 Re: allow building trusted languages without the untrusted versions
Previous Message Stephen Frost 2022-05-25 17:49:40 Re: allow building trusted languages without the untrusted versions