Re: [PATCHES] Roles - SET ROLE Updated - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [PATCHES] Roles - SET ROLE Updated
Date
Msg-id 20050722144305.GQ24207@ns.snowman.net
Whole thread Raw
In response to Re: [PATCHES] Roles - SET ROLE Updated  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] Roles - SET ROLE Updated  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: regressin failure on latest CVS
Next
From: Sam Mason
Date:
Subject: Re: Constraint Exclusion on all tables