Re: [PATCHES] Roles - SET ROLE Updated
От | Stephen Frost |
---|---|
Тема | Re: [PATCHES] Roles - SET ROLE Updated |
Дата | |
Msg-id | 20050722144305.GQ24207@ns.snowman.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] Roles - SET ROLE Updated (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] Roles - SET ROLE Updated
|
Список | pgsql-hackers |
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > 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. 'SET ROLE all' is nonstandard but done in practice. > 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. This is nonstandard and not done in practice. Authorization changes being allowed by 'SET ROLE' is what the spec calls for. Not supporting that ability would be unfortunate and it seems there'd be no point to having 'SET ROLE' at all. Stephen
В списке pgsql-hackers по дате отправления: