Re: [HACKERS] Row Level Security UPDATE Confusion
От | Rod Taylor |
---|---|
Тема | Re: [HACKERS] Row Level Security UPDATE Confusion |
Дата | |
Msg-id | CAHz80e4GbyFWmeZjJusN3LtOFstA+TKtX6ohiqtgZ7Ms=ZOzgA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Row Level Security UPDATE Confusion (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [HACKERS] Row Level Security UPDATE Confusion
Re: [HACKERS] Row Level Security UPDATE Confusion |
Список | pgsql-hackers |
Hmm.
CREATE POLICY split_select ON t FOR SELECT TO split USING (value > 0);
CREATE POLICY split_update ON t FOR UPDATE TO split USING (value < 10) WITH CHECK (value > 2);
SET session authorization split;
update t set value = 100 where value = 4; -- 1 record changed
CREATE POLICY split_update ON t FOR UPDATE TO split USING (value < 10) WITH CHECK (value > 2);
SET session authorization split;
update t set value = 100 where value = 4; -- 1 record changed
update t set value = 5 where value = 100; -- 0 records changed
However, despite INSERT also functioning the same for both styles of commands it's definitely not obeying the `cannot give away records` rule:
CREATE USER simple;
CREATE USER split;
CREATE TABLE t(value int);
grant select, update, insert, delete on table t to simple, split;
INSERT INTO t values (1), (2);
ALTER TABLE t ENABLE ROW LEVEL SECURITY;
CREATE POLICY simple_all ON t TO simple USING (value > 0) WITH CHECK (true);
CREATE POLICY split_select ON t FOR SELECT TO split USING (value > 0);
CREATE POLICY split_insert ON t FOR INSERT TO split WITH CHECK (true);
SET session authorization simple;
INSERT INTO t VALUES (3), (-3);
SELECT * FROM t;
value
-------
1
2
3
(3 rows)
SET session authorization split;
INSERT INTO t VALUES (4), (-4);
SELECT * FROM t;
value
-------
1
2
3
4
(4 rows)
SET session authorization default;
SELECT * FROM t;
value
-------
1
2
3
-3
4
-4
(6 rows)
regards,CREATE USER split;
CREATE TABLE t(value int);
grant select, update, insert, delete on table t to simple, split;
INSERT INTO t values (1), (2);
ALTER TABLE t ENABLE ROW LEVEL SECURITY;
CREATE POLICY simple_all ON t TO simple USING (value > 0) WITH CHECK (true);
CREATE POLICY split_select ON t FOR SELECT TO split USING (value > 0);
CREATE POLICY split_insert ON t FOR INSERT TO split WITH CHECK (true);
SET session authorization simple;
INSERT INTO t VALUES (3), (-3);
SELECT * FROM t;
value
-------
1
2
3
(3 rows)
SET session authorization split;
INSERT INTO t VALUES (4), (-4);
SELECT * FROM t;
value
-------
1
2
3
4
(4 rows)
SET session authorization default;
SELECT * FROM t;
value
-------
1
2
3
-3
4
-4
(6 rows)
Rod
On Fri, May 5, 2017 at 12:10 PM, Stephen Frost <sfrost@snowman.net> wrote:
Rod, Robert,
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Fri, Apr 14, 2017 at 9:16 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > I agreed already up-thread that there's an issue there and will be
> > looking to fix it. That comment was simply replying to Rod's point that
> > the documentation could also be improved.
>
> OK, thanks. The wrap for the next set of minor releases is, according
> to my understanding, scheduled for Monday, so you'd better jump on
> this soon if you're hoping to get a fix out this time around.
The attached patch against master fixes this issue. Rod, if you get a
chance, would be great for you to check that you no longer see a
difference between the single ALL policy and the split SELECT/UPDATE
policies.
Thanks!
Stephen
--
Rod Taylor
В списке pgsql-hackers по дате отправления: