Re: sandboxing untrusted code

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>, Jacob Champion <jacob.champion@enterprisedb.com>
Date: 2026-04-18T19:26:33Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Returning to this topic after some time, I have realized that both of
> these rules are inadequate.
> ... As soon as
> the attacker has *any* influence over what code the victim calls,
> there's a danger of a "confused deputy" attack.

This is true, but I think it's hopeless to imagine that a technical
solution can stop that type of attack altogether.  The deception
might happen entirely outside our system; the classical example
being where somebody persuades you to copy-and-paste some shell
code into your terminal window without fully understanding it.

It's certainly likely that there's room for improvement of your
sandboxing ideas, but you shouldn't abandon them because they don't
solve some insoluble problems.  If we can make large classes of
attacks infeasible at reasonable cost, we've still accomplished
a lot.

			regards, tom lane



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix possible crash in tablesync worker.

  2. Display 'password_required' option for \dRs+ command.

  3. Restart the apply worker if the 'password_required' option is changed.

  4. Fix possible logical replication crash.

  5. Add new predefined role pg_create_subscription.

  6. Expand AclMode to 64 bits

  7. More cleanup of a2ab9c06ea.

  8. Respect permissions within logical replication.

  9. Improve table locking behavior in the face of current DDL.