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
