From: | Nico Williams <nico(at)cryptonector(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(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 22:00:12 |
Message-ID: | 20171018220011.GF4496@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <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...
I don't worry about superusers.
However, I'd like for there to be a way to drop privileges permanently
for a session. Something like SET SESSION AUTHORIZATION WITH NORESET
(ala MySQL) or SET SESSION AUTHENTICATION.
> > 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.
Good point. So a function. Got it.
> I'd probably expose the stack as an array...
I agree, but that would be more expensive, since it means marshalling
all the information, even if the caller only wants one specific item.
Whereas accessing a specific frame by number is much simpler and
performant (no allocation).
It's also easier to not have to do something like.. parsing than the
PG_CONTEXT, instead accessing each of any number of attributes we might
expose from each frame.
Nico
--
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-10-18 23:08:13 | Re: 64-bit queryId? |
Previous Message | Peter Geoghegan | 2017-10-18 21:52:41 | Re: [COMMITTERS] pgsql: Fix traversal of half-frozen update chains |