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

From Tom Lane
Subject Re: Allowing to create LEAKPROOF functions to non-superuser
Date
Msg-id 3044710.1618262060@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allowing to create LEAKPROOF functions to non-superuser  (Andres Freund <andres@anarazel.de>)
Responses Re: Allowing to create LEAKPROOF functions to non-superuser  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2021-04-12 23:51:02 +0300, Andrey Borodin wrote:
>> Do I risk having some extra superusers in my installation if I allow
>> everyone to create LEAKPROOF functions?

> I think that depends on what you define "superuser" to exactly
> be. Defining it as "has a path to executing arbitrary native code", I
> don't think, if implemented sensibly, allowing to set LEAKPROOF on new
> functions would equate superuser permissions. But you soon after might
> hit further limitations where lifting them would have such a risk,
> e.g. defining new types with in/out functions.

I think the issue here is more that superuser = "able to break the
security guarantees of the database".  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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Allowing to create LEAKPROOF functions to non-superuser
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade check for invalid role-specific default config