On 21 December 2012 14:48, Kevin Grittner <kgri...@mail.com> wrote: > Kohei KaiGai wrote: > >>> I don't think I like ALTER TABLE as a syntax for row level >>> security. How about using existing GRANT syntax but allowing a >>> WHERE clause? That seems more natural to me, and it would make >>> it easy to apply the same conditions to multiple types of >>> operations when desired, but use different expressions when >>> desired. >> >> It seems to me this syntax gives an impression that row-security >> feature is tightly combined with role-mechanism, even though it >> does not need. For example, we can set row-security policy of >> primary key is even/odd number, independent from working role. > > Is there some high-level discussion of the concept of row level > security that operates independently of roles? I'm having a little > trouble getting my head around the idea, there is no README in the > patch, and the Wiki page on RLS hasn't been updated for two and a > half years and seems to be mainly discussing the possibility of > adding non-leaky views (which we now have). If it doesn't control > which roles have access to which rows, what does it do, > conceptually? (A URL to a page explaining this would be fine.)
There's some docs there, but that needs improving. Each table has a single security clause. The clause doesn't enforce that it must contain something that depends on role, but that is the most easily understood usage of it. We do that to ensure that you can embed the intelligence into a function, say hasRowLevelAccess(), which doesn't have any provable relationship on role, and maybe wouldn't do anything in unit test, yet clearly in production it would do so. It would be easy enough to include read/write variable clauses by using a function similar to TG_OP for triggers, e.g. StatementType. That would make the security clause that applied only to reads into something like this (StatementType('INSERT, UPDATE') OR other-quals). If you push for GRANT ... WHERE then you may as well just say you want the patch cancelled in this release. There's no way to analyze, design and code something like that in 3 weeks. As I've said, I single table-level policy is much easier to manage anyway. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers