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 20:34:54
Message-ID: 2005351.1653510894@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 agree that this seems to need more discussion and explanation as it
> isn't actually sufficient by itself for "anyone who wants to disallow
> file system access" as the initial post claimed. If there isn't
> sufficient explanation coming forward to support this change by itself
> then we can reject it, but I don't think it makes sense to try and morph
> it into something a lot more generic and a lot harder to actually get
> right and document and guarantee.

The reason I pushed the discussion in that direction was that I was
curious to see if --disable-disk-access could actually be a thing.
If it could, it'd have clear utility for at least some service providers.
But it seems the (preliminary?) conclusion is "no, we still can't do that
in any way that's credibly bulletproof". So yeah, that justification
for the currently-proposed patch doesn't seem to hold water.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zheng Li 2022-05-25 20:42:29 Re: logical decoding and replication of sequences
Previous Message Stephen Frost 2022-05-25 20:27:15 Re: allow building trusted languages without the untrusted versions