From PostgreSQL wiki
This page is for discussion of implementing RLS in PostgreSQL.
Previous discussion of RLS in PG
- Josh Berkus on RLS in PG, Part 1
- Josh Berkus on RLS in PG, Part 2
- SEPostgreSQL_Specifications Specifications for SEPostgreSQL, includes RLS
Articles/Documentation of existing RLS implementations
- Oracle RLS Article, Part 1
- Oracle RLS Article, Part 2
- Oracle RLS and VPD Article
- SQL Server RLS with Classified Systems
- IBM/DB2 RLS Documentation
- PCI Compliant implementations
- Classified Environments
Components of an implementation
- Planner (necessary?)
- Covert Channel
- If we tries to insert a value which conflicts to PK constraint, we can estimate existence of invisible PK from errors.
- Ditto, for FK. If we tries to remove a FK tuple referenced by invisible PK, we can estimate existence of invisible PK from errors.
- We shall not care about this issue. Prior commercial database products with row-level security also don't support such a restriction due to the technical difficulty.
- Order to evaluate row level policy
- User defined function can have lower cost than row-level security policy functions. In this case, user defined (maybe malicious) function can be invoked with arguments which refers invisible tuples.
- There are same issue in VIEWs.
- Row-level policy function/clause has to be evaluated prior to any user given quals.
- TRUNCATE statement
- It removes all the tuples in a certain table, but it may contain unremovable tuples due to the row-level policy.
- idea: Scan the table to check no tuples are unremovable earlier than TRUNCATE. The "abort-mode" can be used we noted in FK-constraint.
- idea: Disallow all the TRUNCATE, if the table has row-level policy.
- COPY TO statement
- We also need to apply row-level policy on COPY TO statement to avoid information leaks.
- idea: COPY tblname TO xxx; can be replaced by COPY (SELECT * FROM tblname) TO xxx;.
- Table inheritance
- What policy should be applied on the parent and child relations.
- idea: Also copy row-level policies from the parent tables.
- Foreign Key constraint
- FK constraint is
- idea: We can provide two modes: The first is filter-mode, the second is abort-mode.
- filter-mode: A normal mode. Row-level policy is evaluated earlier than user given condition, and returns false, if violated.
- abort-mode: A special internal mode. Row-level policy is evaluated after all the condition, and raises an error, if violated. The condition shall be evaluated earlier than row-level policy, the query has to be trusted. Such as queries in FK constraint.
- With RLS
- Without RLS
- Integration with external security manager (eg: SELinux, SMACK)
- The way to manage security label of tuples