Re: function with security definer

On Mon, 24 Mar 2003, Tom Lane wrote:

> Tomasz Myrta <jasiek(at)klaster(dot)net> writes:
>
> > [ Can't do SET SESSION AUTHORIZATION in a postgres-owned function ]
>
> That's because SET SESSION AUTHORIZATION looks to the original login
> userid, not the current effective userid, to decide whether you're
> allowed to do it. If it didn't work that way, a superuser couldn't
> switch to any other identity after becoming a nonprivileged user.

So what if it went like this:

- set session authorization on "logged as superuser" acts
as before

- as a bonus allow superuser owned SECURITY DEFINER functions
to set session authorization when called by unpriv. user.

- it could also be possible for superuser to drop privs
permanently, with SET PERMANENT SESSION AUTHORIZATION.
(which just sets login ids to the new value)

--
Antti Haapala