Re: [v9.4] row level security

On 9/1/13 5:54 PM, Greg Stark wrote:
> So I think up above Tom is wrong about why it's ok that INSERT leaks
> keys when it reports a unique key violation. The reason why it's ok
> that there's a covert channel there is that the DBA can avoid that
> covert channel by being careful when creating unique constraints. He
> or she should be aware that creating a unique constraint implicitly
> provides a kind of limited access to data to users who have INSERT
> privilege even if they lack the real SELECT privilege.

And if someone can INSERT values that they can't actually see once 
they're committed, that's a similarly bad we should describe.  People 
should be dumping their trash in their neighbor's yard.  I think 
eventually this needs to be wrestled to the ground in a robust way.  I 
want to see if all unique violations might be changed to give less 
information in this sort of RLS context.

One rough early idea is to create a new error condition that means you 
hit something protected by RLS, but doesn't leak any more information 
than that.  Just a generic "Security restriction operation" that comes 
out of fishing for keys, inserting outside your area, etc.  I want to 
think through some use cases and review the code to see whether that 
concept helps or not.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com