On 2012-12-19 18:25, Robert Haas wrote:
On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote:
postgres=> INSERT INTO t1 VALUES (4,'ddd');
INSERT 0 1
postgres=> INSERT INTO t1 VALUES (5,'eee');
ERROR: new row for relation "t1" violates row-secirity
DETAIL: Failing row contains (5, eee).
I've argued against this before - and maybe I should drop my
objection, because a number of people seem to be on the other side.
But I still think there will be some people who don't want this
behavior. Right now, for example, you can give someone INSERT but not
SELECT permission on a table, and they will then be able to put rows
into the table that they cannot read back. Similarly, in the RLS
case, it is not necessarily undesirable for a user to be able to
insert a row that they can't read back; or for them to be able to
update a row from a value that they can see to one that they cannot.
Some people will want to prohibit that, while others will not.
Maybe it is an idea to provide different RLS expressions for read and
write. I remember reading a scenario (it might be well known in security
land) where it is possible to write to authorization levels >= users
level, and read levels <= the users level. In this setup Kevin's address
example is possible, a user could write to e.g. the highest level, but
then not read it anymore if his own level was lower than the highest.
This setup also shows that to implement it, one would need a different
expression for read and write (or the rls expression should know the
query's commandtype).
regards,
Yeb
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
