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 <peter_e@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 <kaigai@kaigai.gr.jp>