Hi, On 2023-02-28 08:37:02 -0500, Robert Haas wrote: > On Mon, Feb 27, 2023 at 7:37 PM Jeff Davis <pg...@j-davis.com> wrote: > > > Yeah. That's the idea I was floating, at least. > > > > Isn't that a hard problem; maybe impossible? > > It doesn't seem that hard to me; maybe I'm missing something. > > The existing SECURITY_RESTRICTED_OPERATION flag basically prevents you > from tinkering with the session state. If we also had a similar flags > like DATABASE_READS_PROHIBITED and DATABASE_WRITES_PROHIBITED (or just > a combined DATABASE_ACCESS_PROHIBITED flag) I think that would be > pretty close to what we need. The idea would be that, when a user > executes a function or procedure owned by a user that they don't trust > completely, we'd set > SECURITY_RESTRICTED_OPERATION|DATABASE_READS_PROHIBITED|DATABASE_WRITES_PROHIBITED. > And we could provide a user with a way to express the degree of trust > they have in some other user or perhaps even some specific function, > e.g.
ISTM that this would require annotating most functions in the system. There's many problems besides accessing database contents. Just a few examples: - dblink functions to access another system / looping back - pg_read_file()/pg_file_write() allows almost arbitrary mischief - pg_stat_reset[_shared]() - creating/dropping logical replication slots - use untrusted PL functions - many more A single wrongly annotated function would be sufficient to escape. This includes user defined functions. This basically proposes that we can implement a safe sandbox for executing arbitrary code in a privileged context. IMO history suggests that that's a hard thing to do. Am I missing something? Greetings, Andres Freund