Bryn Jeffries writes:
> Tom Lane wrote
>> I think you might be able to do something with invoking untrusted code
>> inside a SECURITY DEFINER function. That context disables both SET ROLE
>> and SET SESSION AUTHORIZATION. I would not want to bet a lot on that
>> being bulletproof, however.
> Me
Melvin Davidson wrote:
>> The problem for me is that SET ROLE can be reversed with SET ROLE
>> NONE or RESET ROLE, so a user could set the role to access rows that
>> they should not be able to see.
>
> This is only partially true. While they can do SET ROLE NONE & RESET ROLE,
> they Cannot SET ROL
Tom Lane wrote
>> I have a question about preventing SET ROLE from being reset within a
>> session.
>
> You can't; per SQL standard, SET ROLE NONE is supposed to do exactly that.
>
> I think you might be able to do something with invoking untrusted code
> inside a SECURITY DEFINER function. That
Bryn Jeffries writes:
> I have a question about preventing SET ROLE from being reset within a session.
You can't; per SQL standard, SET ROLE NONE is supposed to do exactly that.
I think you might be able to do something with invoking untrusted code
inside a SECURITY DEFINER function. That conte
>The problem for me is that SET ROLE can be reversed with SET ROLE >NONE or
RESET ROLE, so a user could set the role to access rows that >they should
not be able to see.
*This is only partially true. While they can do SET ROLE NONE & RESET ROLE,
they Cannot SET ROLE to a role they have not been g
