On 21 December 2012 14:48, Kevin Grittner <kgrittn@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