Re: sandboxing untrusted code
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Noah Misch <noah@leadboat.com>, Jacob Champion <jacob.champion@enterprisedb.com>
Date: 2026-04-18T20:04:55Z
Lists: pgsql-hackers
On Sat, Apr 18, 2026 at 3:33 PM Andres Freund <andres@anarazel.de> wrote: > > 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. Absolutely. I'm confident we can't prevent that attack with any sort of technological safeguard, and trying would be a bad idea. > > 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. > > Agreed. Even if there are some holes, it sounds like it'd rather drastically > increase the likelihood of making such subversion attempts noticeable. That on > its own is extremely valuable. Thanks to both of you for the quick and encouraging responses. To be clear, I wasn't planning to give up, but I did think it was worth documenting the discovery of a clear oversight in my previous proposal. It's actually a bit unclear to me how feasible "argument choosing" attacks are (where you try to get the bad action to happen while the victim's code or the code of someone they trust is running) as compared with direct attacks (where your code tries to do a bad action directly while running with their privileges). However, my guess is that the answer is "feasible enough that we'd be pretty silly to ignore that risk while designing a feature of this type". Obviously, the perfect can be the enemy of the good, but equally, an insufficiently ambitious scope can result into doing a lot of work for very little actual gain. At any rate, it's not time to make a scope decision yet: more research is needed before committing deeply to any particular course of action. I'm happy to hear your thoughts but let's reserve judgement until the research is in. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix possible crash in tablesync worker.
- b5c517379a40 16.0 landed
-
Display 'password_required' option for \dRs+ command.
- 19e65dff38bd 16.0 landed
-
Restart the apply worker if the 'password_required' option is changed.
- c1cc4e688b60 16.0 landed
-
Fix possible logical replication crash.
- e7e7da2f8d57 16.0 landed
-
Add new predefined role pg_create_subscription.
- c3afe8cf5a1e 16.0 landed
-
Expand AclMode to 64 bits
- 7b378237aa80 16.0 cited
-
More cleanup of a2ab9c06ea.
- 96a6f11c0625 15.0 landed
-
Respect permissions within logical replication.
- a2ab9c06ea15 15.0 landed
-
Improve table locking behavior in the face of current DDL.
- 2ad36c4e44c8 9.2.0 cited