Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function - Mailing list pgsql-general

From Adrian Klaver
Subject Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function
Date
Msg-id bc2b9760-3597-477a-b199-633ba3ac36e5@aklaver.com
Whole thread Raw
In response to Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function  (Dominique Devienne <ddevienne@gmail.com>)
Responses Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function
Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function
List pgsql-general
On 7/31/25 04:37, Dominique Devienne wrote:
> On Thu, Jul 31, 2025 at 11:35 AM Guillaume Lelarge
> <guillaume.lelarge@dalibo.com> wrote:
>> On 31/07/2025 10:41, Dominique Devienne wrote:
>>> On Wed, Jul 30, 2025 at 9:42 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>>> how can has_table_privilege() "lie" like this?
>>
>> It doesn't lie. The role has DELETE privilege. I guess what it lacks is
>> the SELECT privilege. If you do a "DELETE FROM ... WHERE ...", you need
>> the SELECT privilege to perform the WHERE. Without "WHERE ...", it would
>> work without the SELECT privilege.
> 
> Right on the money! Merci Guillaume!!! --DD
> 
> PQ: NOTICE: can DELETE = t
> PQ: NOTICE: can SELECT = f

So the below from the original post was not correct:

"My setup ensures that the role I SET LOCAL ROLE to, has (indirectly)
been granted DMLs on that table."


-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function
Next
From: "David G. Johnston"
Date:
Subject: Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function