Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-19 Thread Nico Williams
A bit more about why I want this. Suppose you have an app like PostgREST (a RESTful, Haskell-coded, HTTP front-end for PostgreSQL). PostgREST basically a proxy for PG access. Users authenticate to the proxy. The proxy authenticates to PG with its own credentials, then it does something like

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 Thread Nico Williams
On Wed, Oct 18, 2017 at 02:45:47PM -0700, David G. Johnston wrote: > On Wed, Oct 18, 2017 at 2:30 PM, Nico Williams > wrote: > > On Wed, Oct 18, 2017 at 02:13:29PM -0700, David G. Johnston wrote: > > > > More useful than this, for me, would be a way to get the top-most

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 Thread David G. Johnston
On Wed, Oct 18, 2017 at 2:30 PM, Nico Williams wrote: > On Wed, Oct 18, 2017 at 02:13:29PM -0700, David G. Johnston wrote: > > > More useful than this, for me, would be a way to get the top-most user. > > > > That would be "session_user"? > > It's not quite since there's a

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 Thread Nico Williams
On Wed, Oct 18, 2017 at 02:13:29PM -0700, David G. Johnston wrote: > > More useful than this, for me, would be a way to get the top-most user. > > That would be "session_user"? It's not quite since there's a difference between SET SESSION AUTHORIZATION and SET SESSION ROLE. But yes, it's what

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 Thread David G. Johnston
On Wed, Oct 18, 2017 at 2:08 PM, Nico Williams wrote: > On Wed, Oct 18, 2017 at 01:43:30PM -0700, David G. Johnston wrote: > > More useful than this, for me, would be a way to get the top-most user. > > ​That would be "session_user"?​ > Introducing the concept of a stack

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 Thread Nico Williams
On Wed, Oct 18, 2017 at 01:43:30PM -0700, David G. Johnston wrote: > 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"

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 Thread David G. Johnston
On Wed, Oct 18, 2017 at 1:26 PM, Nico Williams 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

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 Thread Nico Williams
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)? Nico -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 Thread Pavel Stehule
2017-10-18 22:01 GMT+02:00 Nico Williams : > It'd be nice if SECURITY DEFINER functions could see what user invoked > them, but current_user is the DEFINER user, naturally, since that's how > this is done in fmgr_security_definer(). > > I was thinking that

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 Thread Nico Williams
Alternatively, a way to get at the OuterUserId? Or the outer-most current_user in the function stack? I should explain why I need this: for audit functionality where I want the triggers' procedures to be SECURITY DEFINER so only they can write to audit tables and such, but I want them to see the

[HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 Thread Nico Williams
It'd be nice if SECURITY DEFINER functions could see what user invoked them, but current_user is the DEFINER user, naturally, since that's how this is done in fmgr_security_definer(). I was thinking that fmgr_security_definer() could keep a global pointer to a linked list (with automatic nodes)