On Wed, Oct 26, 2016 at 1:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> This might work for RLS policies, if they can only reference a single
>> table, but I can't see how it's going to work for security barrier
>> views. For example, consider CREATE VIEW v WITH (security_barrier) AS
>> SELECT * FROM x, y WHERE x.a = y.a followed by SELECT * FROM v WHERE
>> leak(somefield). somefield is necessarily coming from either x or y,
>> and you can't let it be passed to leak() except for rows where the
>> join qual has been satisfied.
>
> Right, so quals from above the SB view would have to not be allowed to
> drop below the join level (but they could fall *to* the join level,
> where they'd be applied after the join's own quals). I mentioned that
> in the part of the message you cut. I don't have a detailed design yet
> but it seems possible, and I expect it to be a lot simpler than the Rube
> Goldberg design we've got for SB views now.
OK; it wasn't clear to me that you had considered that case. I'm not
convinced that what you end up with is going to be simpler than what
we have now, but if it is, great. One of the reasons I did the
initial security_barrier stuff this way was to avoid inventing a lot
of new stuff. Subqueries already acted as optimization fences and
that was what we needed for this, so it made sense to me to build on
top of that. Now, if we do build stuff specifically for this purpose,
it can probably be smarter than what we have today, and that is fine.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company