2012/12/9 Simon Riggs <si...@2ndquadrant.com>: > On 9 December 2012 06:08, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >> 2012/12/7 Simon Riggs <si...@2ndquadrant.com>: >>> On 5 December 2012 11:16, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >>> >>>>> * TRUNCATE works, and allows you to remove all rows of a table, even >>>>> ones you can't see to run a DELETE on. Er... >>>>> >>>> It was my oversight. My preference is to rewrite TRUNCATE command >>>> with DELETE statement in case when row-security policy is active on >>>> the target table. >>>> In this case, a NOTICE message may be helpful for users not to assume >>>> the table is always empty after the command. >>> >>> I think the default must be to throw an ERROR, since part of the >>> contract with TRUNCATE is that it is fast and removes storage. >>> >> OK. Does the default imply you are suggesting configurable >> behavior using GUC or something? >> I think both of the behaviors are reasonable from security point >> of view, as long as user cannot remove unprivileged rows. > > Hmm, its difficult one that. I guess this raises the question as to > whether users know they are accessing a table with RLS enabled. If > they don't and we want to keep it that way, then changing TRUNCATE > into DELETE makes sense. > > To issue TRUNCATE you need the correct privilege, which is separate from > DELETE. > > If they have TRUNCATE privilege they should be allowed to remove all > rows, bypassing the row level security. > > If that behavious isn't wanted, then the table owner can create an > INSTEAD OF TRUNCATE trigger that turns the action into a DELETE, which > is then subject to RLS rules. > It seems to me make sense, also. Even though selinux does not define separated permissions for TRUNCATE, the later option will work well for me in case of row-level label based security is configured in the future version. So, I don't implement something special around TRUNCATE, except for paying mention at the documentation.
Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
