I just read on -general that it is envisoned to have a SET command to
temporarily change the effective user id (for superusers only), so that
pg_dump generated scripts won't have to use \connect and be forced to run
under excessively loose permissons.
This isn't hard to do, in fact we probably only need a command to call an
already existing function. I dug around in SQL for a name and the closest
thing was
SET SESSION AUTHORIZATION <value specification> (clause 18.2)
Terminology note: In SQL 'real user' == SESSION_USER, 'effective user' ==
CURRENT_USER. So this command doesn't do it. But the logical choice
would obviously be
SET CURRENT AUTHORIZATION <value specification>
This is nice, but the other end of the plan doesn't actually want to play
along. In clause 11.1 SR 2b) it is described that the owner of a new
schema defaults to the *session* user. (Note that at the end of the day
tables and other lowly objects won't have an owner anymore. In any case
they should currently behave in that aspect as schemas would.)
I say we ignore this requirement, since it's not consistent with Unix
anyway (Files created by setuid programs are owned by the euid.) and it
would destroy our nice plan. ;-)
Another restriction would be that a current user change cannot survive the
end of a transaction. This is implied by the semantics of "suid"
functions and the way we handle exceptions (elog). It could probably be
helped by saving the state of the "authorization stack" at the start of a
transaction. But I'm not sure whether this would be a desirable feature
to have in the first place. Most schema commands are rollbackable now, so
maybe this won't be a large restriction for pg_dump's purposes.
Comments?
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
