Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Roles - SET ROLE Updated

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 14:43:05
Message-ID: 20050722144305.GQ24207@ns.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> 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.

'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

In response to

Responses

pgsql-hackers by date

Next:From: Sam MasonDate: 2005-07-22 14:44:27
Subject: Re: Constraint Exclusion on all tables
Previous:From: Bruce MomjianDate: 2005-07-22 14:40:45
Subject: Re: regressin failure on latest CVS

pgsql-patches by date

Next:From: Joshua D. DrakeDate: 2005-07-22 15:03:28
Subject: Re: COPY FROM performance improvements
Previous:From: Andrew - SupernewsDate: 2005-07-22 14:36:20
Subject: Re: Timezone bugs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group