Re: Interest in a SECURITY DEFINER function current_user stack access mechanism?

A bit more about why I want this.

Suppose you have an app like PostgREST (a RESTful, Haskell-coded, HTTP
front-end for PostgreSQL). PostgREST basically a proxy for PG access.

Users authenticate to the proxy. The proxy authenticates to PG with its
own credentials, then it does something like SET ROLE or SET SESSION
AUTHORIZATION to impersonate the user to PG.

Now suppose you want to support impersonation in such a proxy. That is,
that user "Joe" can impersonate "Jane", for example. So what you do is
you have the proxy do this:

-- This is the role authenticated to the proxy:
SET SESSION AUTHORIZATION <role authenticated to proxy>;

-- This is the requested impersonation, and succeeds only if the first
-- role has been GRANTed the second:
SET SESSION ROLE <role to be impersonated by authenticated role>;

Convenient!

Now, if you want to... audit what Joe does, you may want to record both,
the session_user (Joe) and the current_user (Jane) as you write the
audit trail. Naturally, that's desirable, and it works...

...unless the audit procedures are SECURITY DEFINER. Then they don't
see the current_user. They see the session_user, but can't see who the
session user was impersonating.

Hence I want to be able to look back through the [security definer]
function invocation stack to find what current_user was at the
top-level, or even just the calling function's current_user.

Now, since this is a proxy, a workaround is to store the impersonated
role name in an application defined GUC. But if ever you wanted to give
users direct PG access (one might! it should be possible), then that's
not enough because they can set that GUC. So it really has to be that
the audit procedures can look up the stack.

(When you give out direct PG access you really want to make those audit
procedures SECURITY DEFINER, so they can do DMLs on tables that the
session_user can't.)

This isn't urgent _for me_, but it is a real problem.

Nico
--