Re: [PATCHES] Roles - SET ROLE Updated
От | Tom Lane |
---|---|
Тема | Re: [PATCHES] Roles - SET ROLE Updated |
Дата | |
Msg-id | 29070.1122040404@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] Roles - SET ROLE Updated (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [PATCHES] Roles - SET ROLE Updated
|
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > It sounds like this is essentially if 'SET ROLE all;' is allowed or not. > If you disallow 'SET ROLE all;' (and therefore not do it on session > start) then you would get this behaviour. I certainly see that as a > reasonable option though I think we'd want to allow 'SET ROLE all;' for > backwards compatibility to group-based systems. 'SET ROLE all' is nonstandard; it will complicate the implementation a great deal; and it creates a problem with the permissions environment of a SECURITY DEFINER function being different from that seen at the outer level by the same user. I think a better answer is to have a "rolinherit" flag in pg_authid, which people can set "off" for spec compatibility or "on" for backwards compatibility to the GROUP feature. In either setting, the permissions given to a particular authid are clear from pg_authid and don't vary depending on magic SET variables. regards, tom lane
В списке pgsql-hackers по дате отправления: