Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism? - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism?
Date
Msg-id CAKFQuwaLsT7MFOu5O0j0_sPAtdxU7H6LUEA0bfUmYGPZj1Tk4A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism?  (Nico Williams <nico@cryptonector.com>)
Responses Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism?
List pgsql-hackers
On Wed, Oct 18, 2017 at 1:26 PM, Nico Williams <nico@cryptonector.com> wrote:
On Wed, Oct 18, 2017 at 10:15:01PM +0200, Pavel Stehule wrote:
> there is a function session_user() already

But it doesn't do this.  Are you saying that I should add a
session_user(int)?


​Regardless of the merits of the proposed feature, the function "session_user" is SQL-defined and should not be modified or enhanced.

I could see "calling_role()" being useful - it returns the same value as "current_role" normally and in security invoker functions while in a security definer function it would return whatever current_role would have returned if the function was a security invoker (i.e., the role that the system will put back into effect once the security definer function returns).

Introducing the concept of a stack at the SQL level here seems, at first glance, to be over-complicating things.

David J.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] [POC] Faster processing at Gather node
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Fix traversal of half-frozen update chains