On Mon, 24 Mar 2003, Tom Lane wrote:
> Tomasz Myrta <jasiek@klaster.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.
(whichjust sets login ids to the new value)
--
Antti Haapala
