Real/effective user
От | Peter Eisentraut |
---|---|
Тема | Real/effective user |
Дата | |
Msg-id | Pine.LNX.4.30.0104171815550.762-100000@peter.localdomain обсуждение исходный текст |
Ответы |
Re: Real/effective user
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: