2009/11/24 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> BTW, I plan the following steps for the row-level security.
> | * A facility to put "security label OID" within the tuple header.
> | * System column support to print out the security context.
> | (This system column shall be writable to relabel)
> | * Pure-SQL row-level security checks, something like Oracle Private
> | Database which allows user defined access control decision function.
> | * SELinux aware row-level checks on the virtual private database stuff.
> V It can be implemented as one of the decision making functions.
I think we're getting ahead of ourselves talking about row-level
security at this point, but FWIW I have a lot of concerns about how
the previous version of this feature was designed. In particular, I
think we should set up row-level security in a way that (1) allows it
to be used for purposes other than SE-Linux and (2) allows
row-filtering to take advantage of indices. If I have a table with a
million rows, but only rights to see 100 of them, the system
administrator should be able to define an index that will allow the
100 I can see to be fetched via a bitmap-index scan rather than a
seq-scan with a probe for every row.
...Robert
