From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Nico Williams <nico(at)cryptonector(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Interest in a SECURITY DEFINER function current_user stack access mechanism? |
Date: | 2017-10-18 21:45:47 |
Message-ID: | CAKFQuwbSvMkvLsephaFzZv3Ei3N2D+fCwzpsjXGHs3NiuU8bPA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 18, 2017 at 2:30 PM, Nico Williams <nico(at)cryptonector(dot)com>
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 difference between SET SESSION
> AUTHORIZATION and SET SESSION ROLE.
>
> But yes, it's what I'm using now.
>
True, though at that point the superuser who wants to cover their tracks
could probably just edit your functions...
> Really? Why? I mean, there's an implicit function invocation stack
> already. Reifying some bits of the function call stack is useful. I
> can't think of how this particular reification would be dangerous or set
> a bad precedent.
>
Nothing concrete...
>
> Hmmm, oh, I forgot about GET DIAGNOSTICS! The stack is already exposed
> to SQL. Maybe we could add a CURRENT_USER item to GET STACKED
> DIAGNOSTICS or to the PG_CONTEXT.
>
Ideally if implementing what you describe we'd want it accessible from any
procedural language, not just pl/pgsql.
Also, GET STACKED DIAGNOSTICS is documented as being exposed only within an
exception handler.
> > If I was in position to dive deeper I wouldn't foreclose on the stack
> idea
> > but I'd be inclined to see if something else could be made to work with
> > reasonable effort.
>
> I would think that the more general approach, if easy enough to
> implement, would be better. I can (and will) live with using
> session_user instead of current_user, for now. But I'm willing to
> contribute a patch
I'd probably expose the stack as an array...
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-10-18 21:52:41 | Re: [COMMITTERS] pgsql: Fix traversal of half-frozen update chains |
Previous Message | Nico Williams | 2017-10-18 21:30:22 | Re: Interest in a SECURITY DEFINER function current_user stack access mechanism? |