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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism?
Дата
Msg-id CAKFQuwbSvMkvLsephaFzZv3Ei3N2D+fCwzpsjXGHs3NiuU8bPA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism?  (Nico Williams <nico@cryptonector.com>)
Ответы Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism?  (Nico Williams <nico@cryptonector.com>)
Список pgsql-hackers
On Wed, Oct 18, 2017 at 2:30 PM, Nico Williams <nico@cryptonector.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nico Williams
Дата:
Сообщение: Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism?
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Fix traversal of half-frozen update chains