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 по дате отправления: