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

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

Previous
From: Tom Lane
Date:
Subject: Re: Writing Commit Status hint bits (was Re: Constant WAL replay)
Next
From: Bruce Momjian
Date:
Subject: Re: Timezone bugs