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
