2012/12/22 Kevin Grittner <kgri...@mail.com>: > Kohei KaiGai wrote: > >> RLS entry of wiki has not been updated for long time, I'll try to >> update the entry for high-level design in a couple of days. > > Thanks, I think that is essential for a productive discussion of > the issue. > I tried to update http://wiki.postgresql.org/wiki/RLS
I backed to the definition of feature for information security; that requires to ensure confidentiality, integrity and availability (C.I.A) of information asset managed by system. Access control contributes the first two elements. So, I'm inclined RLS feature "eventually" support reader-side and writer-side, to prevent unprivileged rows are read or written. If I could introduce the most conceptual stuff in one statement, it shall be: "Overall, RLS prevents users to read and write rows that does not satisfies the row-security policy being configured on the table by the table owner. Reader-side ensures confidentiality of data, writer-side ensures integrity of data." Also note that, I believe this criteria never deny to have multiple (asymmetric) row-security policy for each command type, as long as we care about problematic scenario properly. 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
