From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Dominique Devienne <ddevienne(at)gmail(dot)com>, Guillaume Lelarge <guillaume(dot)lelarge(at)dalibo(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function |
Date: | 2025-07-31 14:13:16 |
Message-ID: | bc2b9760-3597-477a-b199-633ba3ac36e5@aklaver.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 7/31/25 04:37, Dominique Devienne wrote:
> On Thu, Jul 31, 2025 at 11:35 AM Guillaume Lelarge
> <guillaume(dot)lelarge(at)dalibo(dot)com> wrote:
>> On 31/07/2025 10:41, Dominique Devienne wrote:
>>> On Wed, Jul 30, 2025 at 9:42 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2025-07-31 15:06:45 | Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function |
Previous Message | Tom Lane | 2025-07-31 14:11:53 | Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function |