Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism?
От | Nico Williams |
---|---|
Тема | Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism? |
Дата | |
Msg-id | 20171018220011.GF4496@localhost обсуждение исходный текст |
Ответ на | Re: [HACKERS] Interest in a SECURITY DEFINER function current_userstack access mechanism? ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | 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@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... 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 -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: