On Mon, Dec 6, 2010 at 9:37 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of lun dic 06 23:09:56 -0300 2010:
>> On Mon, Dec 6, 2010 at 2:47 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> >
>> >> Please explain more precisely what is wrong with SET SESSION
>> >> AUTHORIZATION / SET ROLE.
>> >
>> > 1) Session GUCS do not change with a SET ROLE (this is a TODO I haven't
>> > had any time to work on)
>> >
>> > 2) Users can always issue their own SET ROLE and then "hack into" other
>> > users' data.
>>
>> Makes sense. It would be nice to fix those issues, independent of
>> anything else.
>
> It seems plausible to fix the first one, but how would you fix the
> second one? You either allow SET ROLE (which you need, to support the
> pooler changing authorization), or you don't. There doesn't seem to be
> a usable middleground.
You could add a protocol message that does a "permanent" role switch
in a way that can't be undone except by another such protocol message.Then connection poolers could simply refuse to
proxythat particular
message.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
