* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> 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
signature.asc
Description: Digital signature
