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

From Tom Lane
Subject Re: [PATCHES] Roles - SET ROLE Updated
Date
Msg-id 22873.1121980006@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  (Stephen Frost <sfrost@snowman.net>)
Re: [PATCHES] Roles - SET ROLE Updated  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> Perhaps the specification isn't but I'm pretty sure other
> implementations follow the SET ROLE -> current authorization
> identifier (and thus dropping other rights granted to the CURRENT_USER).

My current reading of 4.31 is that SET ROLE *doesn't* drop rights, which
means we need to rethink all of this.  However, on this point:

>>> Technically I believe this
>>> actually allows multiple levels of 'SET ROLE's to be done and for 'SET
>>> ROLE NONE's to only pull off the top-level.
>>
>> I don't see anything in the spec that suggests that reading to me.

> It's in 4.34.1.1, at least in the SQL2003 specification, and it reads:
> "This stack is maintained using a "last-in, first-out" discipline, and
> effectively only the top cell is visible.

Yes, but the only events that push or pop stack entries are entry/exit
of an external procedure (think SECURITY DEFINER procedure).  SET ROLE
doesn't push or pop anything, it just alters the current top entry.
(Which must in fact be the *only* entry, given that SET ROLE is only
allowed at outer level...)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Dawid Kuroczko
Date:
Subject: Re: Constraint Exclusion on all tables
Next
From: Stephen Frost
Date:
Subject: Re: [PATCHES] Roles - SET ROLE Updated