1997-04-27 19:40:13 +02:00
|
|
|
--
|
2000-01-06 07:41:55 +01:00
|
|
|
-- SELECT_VIEWS
|
|
|
|
-- test the views defined in CREATE_VIEWS
|
1997-04-27 19:40:13 +02:00
|
|
|
--
|
2000-01-06 07:41:55 +01:00
|
|
|
|
1997-12-01 03:46:13 +01:00
|
|
|
SELECT * FROM street;
|
1997-04-27 19:40:13 +02:00
|
|
|
|
1998-02-23 14:59:34 +01:00
|
|
|
SELECT name, #thepath FROM iexit ORDER BY 1, 2;
|
1997-04-27 19:40:13 +02:00
|
|
|
|
1997-12-01 03:46:13 +01:00
|
|
|
SELECT * FROM toyemp WHERE name = 'sharon';
|
2012-01-18 04:07:24 +01:00
|
|
|
|
|
|
|
--
|
|
|
|
-- Test for Leaky view scenario
|
|
|
|
--
|
2012-01-24 14:38:20 +01:00
|
|
|
CREATE ROLE regress_alice;
|
2012-01-18 04:07:24 +01:00
|
|
|
|
|
|
|
CREATE FUNCTION f_leak (text)
|
|
|
|
RETURNS bool LANGUAGE 'plpgsql' COST 0.0000001
|
|
|
|
AS 'BEGIN RAISE NOTICE ''f_leak => %'', $1; RETURN true; END';
|
|
|
|
|
|
|
|
CREATE TABLE customer (
|
|
|
|
cid int primary key,
|
|
|
|
name text not null,
|
|
|
|
tel text,
|
|
|
|
passwd text
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE TABLE credit_card (
|
|
|
|
cid int references customer(cid),
|
|
|
|
cnum text,
|
|
|
|
climit int
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE TABLE credit_usage (
|
|
|
|
cid int references customer(cid),
|
|
|
|
ymd date,
|
|
|
|
usage int
|
|
|
|
);
|
|
|
|
|
|
|
|
INSERT INTO customer
|
2012-01-24 14:38:20 +01:00
|
|
|
VALUES (101, 'regress_alice', '+81-12-3456-7890', 'passwd123'),
|
|
|
|
(102, 'regress_bob', '+01-234-567-8901', 'beafsteak'),
|
|
|
|
(103, 'regress_eve', '+49-8765-43210', 'hamburger');
|
2012-01-18 04:07:24 +01:00
|
|
|
INSERT INTO credit_card
|
|
|
|
VALUES (101, '1111-2222-3333-4444', 4000),
|
|
|
|
(102, '5555-6666-7777-8888', 3000),
|
|
|
|
(103, '9801-2345-6789-0123', 2000);
|
|
|
|
INSERT INTO credit_usage
|
|
|
|
VALUES (101, '2011-09-15', 120),
|
2013-11-10 15:20:52 +01:00
|
|
|
(101, '2011-10-05', 90),
|
2012-01-18 04:07:24 +01:00
|
|
|
(101, '2011-10-18', 110),
|
|
|
|
(101, '2011-10-21', 200),
|
|
|
|
(101, '2011-11-10', 80),
|
|
|
|
(102, '2011-09-22', 300),
|
|
|
|
(102, '2011-10-12', 120),
|
|
|
|
(102, '2011-10-28', 200),
|
|
|
|
(103, '2011-10-15', 480);
|
|
|
|
|
|
|
|
CREATE VIEW my_property_normal AS
|
|
|
|
SELECT * FROM customer WHERE name = current_user;
|
|
|
|
CREATE VIEW my_property_secure WITH (security_barrier) AS
|
|
|
|
SELECT * FROM customer WHERE name = current_user;
|
|
|
|
|
|
|
|
CREATE VIEW my_credit_card_normal AS
|
|
|
|
SELECT * FROM customer l NATURAL JOIN credit_card r
|
|
|
|
WHERE l.name = current_user;
|
|
|
|
CREATE VIEW my_credit_card_secure WITH (security_barrier) AS
|
|
|
|
SELECT * FROM customer l NATURAL JOIN credit_card r
|
|
|
|
WHERE l.name = current_user;
|
|
|
|
|
|
|
|
CREATE VIEW my_credit_card_usage_normal AS
|
|
|
|
SELECT * FROM my_credit_card_secure l NATURAL JOIN credit_usage r;
|
|
|
|
CREATE VIEW my_credit_card_usage_secure WITH (security_barrier) AS
|
|
|
|
SELECT * FROM my_credit_card_secure l NATURAL JOIN credit_usage r;
|
|
|
|
|
|
|
|
GRANT SELECT ON my_property_normal TO public;
|
|
|
|
GRANT SELECT ON my_property_secure TO public;
|
|
|
|
GRANT SELECT ON my_credit_card_normal TO public;
|
|
|
|
GRANT SELECT ON my_credit_card_secure TO public;
|
|
|
|
GRANT SELECT ON my_credit_card_usage_normal TO public;
|
|
|
|
GRANT SELECT ON my_credit_card_usage_secure TO public;
|
|
|
|
|
|
|
|
--
|
|
|
|
-- Run leaky view scenarios
|
|
|
|
--
|
2012-01-24 14:38:20 +01:00
|
|
|
SET SESSION AUTHORIZATION regress_alice;
|
2012-01-18 04:07:24 +01:00
|
|
|
|
|
|
|
--
|
|
|
|
-- scenario: if a qualifier with tiny-cost is given, it shall be launched
|
|
|
|
-- prior to the security policy of the view.
|
|
|
|
--
|
|
|
|
SELECT * FROM my_property_normal WHERE f_leak(passwd);
|
|
|
|
EXPLAIN (COSTS OFF) SELECT * FROM my_property_normal WHERE f_leak(passwd);
|
|
|
|
|
|
|
|
SELECT * FROM my_property_secure WHERE f_leak(passwd);
|
|
|
|
EXPLAIN (COSTS OFF) SELECT * FROM my_property_secure WHERE f_leak(passwd);
|
|
|
|
|
Improve qual pushdown for RLS and SB views
The original security barrier view implementation, on which RLS is
built, prevented all non-leakproof functions from being pushed down to
below the view, even when the function was not receiving any data from
the view. This optimization improves on that situation by, instead of
checking strictly for non-leakproof functions, it checks for Vars being
passed to non-leakproof functions and allows functions which do not
accept arguments or whose arguments are not from the current query level
(eg: constants can be particularly useful) to be pushed down.
As discussed, this does mean that a function which is pushed down might
gain some idea that there are rows meeting a certain criteria based on
the number of times the function is called, but this isn't a
particularly new issue and the documentation in rules.sgml already
addressed similar covert-channel risks. That documentation is updated
to reflect that non-leakproof functions may be pushed down now, if
they meet the above-described criteria.
Author: Dean Rasheed, with a bit of rework to make things clearer,
along with comment and documentation updates from me.
2015-04-27 18:29:42 +02:00
|
|
|
--
|
|
|
|
-- scenario: qualifiers can be pushed down if they contain leaky functions,
|
|
|
|
-- provided they aren't passed data from inside the view.
|
|
|
|
--
|
|
|
|
SELECT * FROM my_property_normal v
|
|
|
|
WHERE f_leak('passwd') AND f_leak(passwd);
|
|
|
|
EXPLAIN (COSTS OFF) SELECT * FROM my_property_normal v
|
|
|
|
WHERE f_leak('passwd') AND f_leak(passwd);
|
|
|
|
|
|
|
|
SELECT * FROM my_property_secure v
|
|
|
|
WHERE f_leak('passwd') AND f_leak(passwd);
|
|
|
|
EXPLAIN (COSTS OFF) SELECT * FROM my_property_secure v
|
|
|
|
WHERE f_leak('passwd') AND f_leak(passwd);
|
|
|
|
|
2012-01-18 04:07:24 +01:00
|
|
|
--
|
|
|
|
-- scenario: if a qualifier references only one-side of a particular join-
|
|
|
|
-- tree, it shall be distributed to the most deep scan plan as
|
|
|
|
-- possible as we can.
|
|
|
|
--
|
|
|
|
SELECT * FROM my_credit_card_normal WHERE f_leak(cnum);
|
|
|
|
EXPLAIN (COSTS OFF) SELECT * FROM my_credit_card_normal WHERE f_leak(cnum);
|
|
|
|
|
|
|
|
SELECT * FROM my_credit_card_secure WHERE f_leak(cnum);
|
|
|
|
EXPLAIN (COSTS OFF) SELECT * FROM my_credit_card_secure WHERE f_leak(cnum);
|
|
|
|
|
|
|
|
--
|
|
|
|
-- scenario: an external qualifier can be pushed-down by in-front-of the
|
2012-02-14 04:20:27 +01:00
|
|
|
-- views with "security_barrier" attribute, except for operators
|
|
|
|
-- implemented with leakproof functions.
|
2012-01-18 04:07:24 +01:00
|
|
|
--
|
|
|
|
SELECT * FROM my_credit_card_usage_normal
|
|
|
|
WHERE f_leak(cnum) AND ymd >= '2011-10-01' AND ymd < '2011-11-01';
|
|
|
|
EXPLAIN (COSTS OFF) SELECT * FROM my_credit_card_usage_normal
|
|
|
|
WHERE f_leak(cnum) AND ymd >= '2011-10-01' AND ymd < '2011-11-01';
|
|
|
|
|
|
|
|
SELECT * FROM my_credit_card_usage_secure
|
|
|
|
WHERE f_leak(cnum) AND ymd >= '2011-10-01' AND ymd < '2011-11-01';
|
|
|
|
EXPLAIN (COSTS OFF) SELECT * FROM my_credit_card_usage_secure
|
|
|
|
WHERE f_leak(cnum) AND ymd >= '2011-10-01' AND ymd < '2011-11-01';
|
|
|
|
|
|
|
|
--
|
|
|
|
-- Test for the case when security_barrier gets changed between rewriter
|
|
|
|
-- and planner stage.
|
|
|
|
--
|
|
|
|
PREPARE p1 AS SELECT * FROM my_property_normal WHERE f_leak(passwd);
|
|
|
|
PREPARE p2 AS SELECT * FROM my_property_secure WHERE f_leak(passwd);
|
|
|
|
EXECUTE p1;
|
|
|
|
EXECUTE p2;
|
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
ALTER VIEW my_property_normal SET (security_barrier=true);
|
|
|
|
ALTER VIEW my_property_secure SET (security_barrier=false);
|
2012-01-24 14:38:20 +01:00
|
|
|
SET SESSION AUTHORIZATION regress_alice;
|
2012-01-18 04:07:24 +01:00
|
|
|
EXECUTE p1; -- To be perform as a view with security-barrier
|
|
|
|
EXECUTE p2; -- To be perform as a view without security-barrier
|
2012-01-24 14:38:20 +01:00
|
|
|
|
|
|
|
-- Cleanup.
|
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
DROP ROLE regress_alice;
|