2009/11/24 KaiGai Kohei <kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
