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 | CAKFQuwaLsT7MFOu5O0j0_sPAtdxU7H6LUEA0bfUmYGPZj1Tk4A@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?
|
Список | pgsql-hackers |
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 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" normally and in security invoker functions while in a security definer function it would return whatever current_role would have returned if the function was a security invoker (i.e., the role that the system will put back into effect once the security definer function returns).
Introducing the concept of a stack at the SQL level here seems, at first glance, to be over-complicating things.
David J.
В списке pgsql-hackers по дате отправления: