Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Dominique Devienne <ddevienne(at)gmail(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-30 16:21:08
Message-ID: 508f71c4-f1b1-4685-921d-bec8b361be10@aklaver.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 7/30/25 08:47, Dominique Devienne wrote:
> On Wed, Jul 30, 2025 at 5:23 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>> On 7/30/25 04:37, Dominique Devienne wrote:
>>> Are there special consideration I'm unaware of, regarding SET ROLE
>>> inside routines?
>
>> What is the ROLE that defined the function?
>
> A 3rd role. But does it matter? Given that this is in SECURITY INVOKER function?

My mistake, a BC(Before Coffee) issue.

> The function and the table belong to yet another role.
> And when we enter the function, we're yet another one (obviously with
> USAGE+EXECUTE, since could call it).
> But once we SET LOCAL ROLE, the effective permissions used should be
> for :OWNER1 and the inherited :SOWNER.

Could this be a search_path and/or naming issue, where the table
SchemaMapping appears in more then one schema or different name case?

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2025-07-30 19:42:39 Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function
Previous Message Dominique Devienne 2025-07-30 15:47:14 Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function