Re: Allowing to create LEAKPROOF functions to non-superuser

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allowing to create LEAKPROOF functions to non-superuser
Date: 2021-04-12 20:51:58
Message-ID: 20210412205158.m5bhyh3uf7znjska@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-04-12 16:37:01 -0400, Tom Lane wrote:
> Andrey Borodin <x4mmm(at)yandex-team(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-04-12 20:54:03 Re: Allowing to create LEAKPROOF functions to non-superuser
Previous Message Andrey Borodin 2021-04-12 20:51:02 Re: Allowing to create LEAKPROOF functions to non-superuser