Now I'm trying to tackle the covert-channel problem that Korotkov pointed out at upthread.
The attached patch works "almost" well. It prevents to print number of rows being filtered if the target plan node is under sub-query with security-barrier attribute; because row- level security feature is constructed on existing security-barrier view infrastructure. One remaining issue is that planner pulls-up underlying relation scan if top-level sub-query is enough simple; probably, in case when targetlist of upper sub-query is compatible with underlying relation scan. See, the example below: postgres=# CREATE TABLE t1 (a int primary key, b int); CREATE TABLE postgres=# INSERT INTO t1 VALUES (1,1111),(2,2222),(3,3333),(4,4444),(5,5555); INSERT 0 5 postgres=# CREATE VIEW v1 WITH(security_barrier) AS SELECT * FROM t1 WHERE a % 2 = 1; CREATE VIEW postgres=# SET enable_seqscan = off; SET postgres=# EXPLAIN ANALYZE SELECT 1 FROM v1 WHERE b BETWEEN 2000 AND 4000; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------- Subquery Scan on v1 (cost=10000000000.00..10000000052.81 rows=1 width=0) (actual time=0.016..0.017 rows=1 loops=1) -> Seq Scan on t1 (cost=10000000000.00..10000000052.80 rows=1 width=8) (actual time=0.014..0.015 rows=1 loops=1) Filter: ((b >= 2000) AND (b <= 4000) AND ((a % 2) = 1)) Total runtime: 0.067 ms (4 rows) According to the scenario that Korotkov pointed out, number of filtered rows shall be printed, thus, it allows to estimate particular value with log(N) times trials. However, this example hides number of rows being done within security-barrier sub- query as I expected. On the other hand, if planner pulled-up underlying relation scan, it does NOT work fine. postgres=# EXPLAIN ANALYZE SELECT * FROM v1 WHERE b BETWEEN 2000 AND 4000; QUERY PLAN ---------------------------------------------------------------------------------------------------------------- Seq Scan on t1 (cost=10000000000.00..10000000052.80 rows=1 width=8) (actual time=0.019..0.021 rows=1 loops=1) Filter: ((b >= 2000) AND (b <= 4000) AND ((a % 2) = 1)) Rows Removed by Filter: 4 Total runtime: 0.055 ms (4 rows) It seems to me we need to prohibit to pull-up security-barrier sub-query here, or to mark underlying relation scan security-barrier attribute to solve this issue. (I'm still looking for which routine handles this pull-up job, however, I didn't find it yet.) How about opinion for this solution? Thanks, 2013/9/7 Peter Eisentraut <pete...@gmx.net>: > On Wed, 2013-08-28 at 13:56 +0200, Kohei KaiGai wrote: >> The attached patch fixed the portion I was pointed out, so its overall >> design has not been changed so much. > > The documentation doesn't build: > > openjade:catalogs.sgml:237:28:X: reference to non-existent ID > "CATALOG-PG-ROWLEVELSEC" > > -- KaiGai Kohei <kai...@kaigai.gr.jp>
explain_hide_filtered.v0.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers