On Fri, Nov 21, 2014 at 6:57 AM, Stephen Frost <sfrost@snowman.net> wrote:
> Are you sure this isn't just another example of an existing issue we
> have wrt column privileges..? I'm working on a patch already to address
> those issues in back-branches and will be considering what needs to be
> done for RLS also.
I thought it was pretty conclusively the case that it wasn't (i.e.
that I definitely had an obligation to figure out a way to get the
security quals appended to the UPDATE predicate). I'm slightly
surprised that you don't immediately agree - after all, I could
manually append a qual that will "stop the leak", since the UPDATE
then won't affect what it shouldn't (though you're still locking the
row, as always happens with ON CONFLICT UPDATE when the WHERE clause
doesn't pass [1], which might need to be considered. But the same is
true with postgres_fdw,)
> One option for RLS is to not produce the 'detail'
> info when RLS exists on the relation, but Robert makes a good point that
> the detail information is valuable results for normal users, so I'm
> hopeful that we'll be able to do better than that.
I agree that losing that would be unfortunate and best avoided.
[1] https://wiki.postgresql.org/wiki/UPSERT#Why_still_lock_row_when_UPDATE_predicate_isn.27t_satisfied.3F
--
Peter Geoghegan
