Re: sandboxing untrusted code

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: sandboxing untrusted code
Date: 2026-06-01 19:05:32
Message-ID: 2840517.1780340732@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... One of the worst things for a security system to do is be
> so annoying that users turn it off, and blocking stuff that a human
> will immediately identify as harmless is a quick route to that goal.

Right. I'm reminded of SELinux, which in its early incarnations
was definitely in the category of "too annoying for normal users".
Red Hat spent literally years sanding down the rough edges, and
since then it's been on-by-default on just about every RH-based
machine, with few problems. Don't underestimate the amount of
effort needed to get to that status.

I was only on the periphery of that work, but from what I recall,
the years of fine-tuning were less about the core mechanisms than
about developing a set of policies that didn't get in people's way.
The corresponding labor here would probably be refining our ideas
about which sets of functions to distinguish and making sure that
all the functions are correctly classified.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Alexander Lakhin 2026-06-01 19:00:00 Re: Improving tracking/processing of buildfarm test failures