Hi,
On 2021-04-12 17:14:20 -0400, Tom Lane wrote:
> I doubt that falsely labeling a function LEAKPROOF can get you more
> than the ability to read data you're not supposed to be able to read
> ... but that ability is then available to all users, or at least all
> users who can execute the function in question. So it definitely is a
> fairly serious security hazard, and one that's not well modeled by
> role labels. If you give somebody e.g. pg_read_all_data privileges,
> you don't expect that that means they can give it to other users.
A user with BYPASSRLS can create public security definer functions
returning data. If the concern is a BYPASSRLS user intentionally
exposing data, then there's not a meaningful increase to allow defining
LEAKPROOF functions.
To me the more relevant concern is that it's hard to determine
LEAKPROOF-ness and that many use-cases for BYPASSRLS do not require the
target to have the technical chops to determine if a function actually
is leakproof. But that seems more an argument for providing a separate
control over allowing to specify LEAKPROOF than against separating it
from superuser.
Greetings,
Andres Freund