On 10/30/2013 11:25 AM, Kohei KaiGai wrote:
> 2013/10/30 Craig Ringer <craig@2ndquadrant.com>:
>> On 10/30/2013 10:50 AM, Tom Lane wrote:
>>> Craig Ringer <craig@2ndquadrant.com> writes:
>>>>> I'd kind of like to see FK constraints affected by RLS for
>>>>> non-superusers, at least as an option.
>>> I think that's a complete nonstarter. Aside from the fact that such a
>>> constraint will have no definable semantics, even the possibility that a
>>> constraint doesn't mean what it appears to mean will prevent us from
>>> making use of FK constraints for optimization --- something that's
>>> pretty high on the planner to-do list.
>>
>> Good point. That's another good argument for FK constraints to disregard
>> RLS. In which case, is there actually any way to determine when an SPI
>> query is being invoked directly from an FK constraint? We'll need a way
>> to tell so RLS can skip adding the row-security check predicate.
>>
> For your reference, my implementation patches on ri_PerformCheck()
> as follows. It didn't skip all the case (only when PK is modified), however,
> its overall idea can be common.
That makes plenty of sense. The only concern that comes immediately to
mind for me there is what happens when the RI trigger, running with
SECURITY_ROW_LEVEL_DISABLED context, does a cascade UPDATE or DELETE
that results in the invocation of user-defined triggers.
Otherwise an RLS-constrained user who owns a table could add a trigger
to that table that, when executed via cascade from an RI check, leaks
information about other tables it queries while RLS is disabled.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services