Re: Allowing to create LEAKPROOF functions to non-superuser - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Allowing to create LEAKPROOF functions to non-superuser
Date
Msg-id 20210412205158.m5bhyh3uf7znjska@alap3.anarazel.de
Whole thread Raw
In response to Re: Allowing to create LEAKPROOF functions to non-superuser  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2021-04-12 16:37:01 -0400, Tom Lane wrote:
> Andrey Borodin <x4mmm@yandex-team.ru> writes:
> > Currently only superuser is allowed to create LEAKPROOF functions
> > because leakproof functions can see tuples which have not yet been
> > filtered out by security barrier views or row level security
> > policies.
>
> Yeah.
>
> > But managed cloud services typically do not provide superuser roles.
>
> This is not a good argument for relaxing superuser requirements.

IDK. I may have been adjacent to people operating database-as-a-service
for too long, but ISTM there's decent reasons for (and also against) not
providing full superuser access. Even outside of managed services it
seems like a decent idea to split the "can execute native code" role
from the "administers an application" role. That reduces the impact a
bug in the application can incur.

There's certain things that are pretty intrinsically "can execute native
code", like defining new 'C' functions, arbitrary ALTER SYSTEM,
arbitrary file reads/writes, etc. Splitting them off from superuser is a
fools errand. But it's not at all clear why adding LEAKPROOF to
functions falls into that category?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Allowing to create LEAKPROOF functions to non-superuser
Next
From: Andres Freund
Date:
Subject: Re: Allowing to create LEAKPROOF functions to non-superuser