[HACKERS] Row Level Security UPDATE Confusion - Mailing list pgsql-hackers

From Rod Taylor
Subject [HACKERS] Row Level Security UPDATE Confusion
Date
Msg-id CAHz80e7Pd4FgDmR=UUDij+oCSf92BKkosRV=12Ra7xMrwQ11YA@mail.gmail.com
Whole thread Raw
Responses Re: [HACKERS] Row Level Security UPDATE Confusion  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
I'm a little confused on why a SELECT policy fires against the NEW record for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem to have that restriction.


DROP TABLE IF EXISTS t;

CREATE USER simple;
CREATE USER split;
CREATE TABLE t(value int);
grant select, update 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_update ON t FOR UPDATE TO split USING (true) WITH CHECK (true);


SET session authorization simple;
SELECT * FROM t;
UPDATE t SET value = value * -1 WHERE value = 1;

SET session authorization split;
SELECT * FROM t;
UPDATE t SET value = value * -1 WHERE value = 2;
/* UPDATE fails with below error:
psql:/tmp/t.sql:24: ERROR:  42501: new row violates row-level security policy for table "t"
LOCATION:  ExecWithCheckOptions, execMain.c:2045
*/

SET session authorization default;
SELECT * FROM t;

This seems consistent in both Pg 9.5 and upcoming Pg 10.


--
Rod Taylor

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange
Next
From: Álvaro Hernández Tortosa
Date:
Subject: Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange