From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [PATCHES] Roles - SET ROLE Updated |
Date: | 2005-07-21 21:06:46 |
Message-ID: | 22873.1121980006@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:
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2005-07-21 21:07:11 | Re: [PATCHES] Roles - SET ROLE Updated |
Previous Message | Dawid Kuroczko | 2005-07-21 20:59:22 | Re: Constraint Exclusion on all tables |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2005-07-21 21:07:11 | Re: [PATCHES] Roles - SET ROLE Updated |
Previous Message | Stephen Frost | 2005-07-21 20:57:20 | Re: [PATCHES] Roles - SET ROLE Updated |