On 2012-12-19 18:25, Robert Haas wrote:
> On Tue, Dec 18, 2012 at 3:39 PM, Kohei KaiGai <kaigai@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