From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] Roles - SET ROLE Updated |
Date: | 2005-07-22 13:53:24 |
Message-ID: | 29070.1122040404@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Stephen Frost <sfrost(at)snowman(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-07-22 14:16:34 | Re: Timezone bugs |
Previous Message | Tom Lane | 2005-07-22 13:40:09 | Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay) |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-07-22 14:16:34 | Re: Timezone bugs |
Previous Message | Tom Lane | 2005-07-22 13:40:09 | Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay) |