Query rewrite problem related to FGAC/RLS/VPD

Question

My problem in related to Fine Grained Access Control / DBMS_RLS.
Let's start with a simple example and elaborate further.
Basic problem:
Let's say we have two tables:
create table LEVEL1( L1NR NUMBER not null, TAG NUMBER);
alter table LEVEL1 add constraint LEVEL1_PK primary key (L1NR);
create table LEVEL2( L1NR NUMBER, L2NR NUMBER not null);
alter table LEVEL2 add constraint LEVEL2_PK primary key (L2NR);
alter table LEVEL2 add constraint LEVEL2_FK foreign key (L1NR) references LEVEL1 (L1NR);
I want to convince the database to rewrite a query that looks like this:
A)
SELECT L1.TAG, L2.L2NR
FROM
LEVEL2 L2
INNER JOIN LEVEL1 L1
ON L2.L1NR = L1.L1NR
WHERE
EXISTS( SELECT 1 FROM LEVEL1 L1B WHERE L1B.L1NR = L2.L1NR)
As L2 will be joined to L1 for my human eye and mind
it is obvious that the where clause is redundant,
and the query is equivalent to:
B)
SELECT L1.TAG, L2.L2NR
FROM
LEVEL2 L2
INNER JOIN LEVEL1 L1
ON L2.L1NR = L1.L1NR
Is there any way to convince the parser/optimizer to remove the redundant join?
Why do I have a query like A) and why I cannot rewrite it myself I will explain below.
For those to ask themselves why do I need such a thing let me elaborate.
We develop an application and we want to enforce security on the data at the row level.
The problem is more complicate than my following example, but the example is good enough.
Let's say that we have an application that makes invoices.
We want to give a user the privilege to make reports on the invoices issued for a category of customers.
I see three main ways to enforce row level security on data:
1) At the application level
2) Using views
3) Using Fine Grained Access Control / DBMS_RLS
Choice 1) is more flexible, but it has a major drawback:
You cannot make the database available for reporting with BI/ad-hoc reporting tools.
And also you have to be careful with every query you write. Or create something that takes care of the security, which can be really tricky.
And it also makes report creation for the application difficult since you need to embed the security system into the reporting module.
If you use Crystal Reports or some other reporting tool to build your application report you've got a problem.
Choices 2) and 3) are somewhat similar, but 3) is more flexible
For those who don't know how FGAC/DBMS_RLS works and don't want to dig deeper here is a short explanation:
DBMS_RLS allows the database developer to attach dynamic where clauses to queries.
It does this by rewriting queries like:
"select blabla from employees"
to "select blabla from (select * from employees where <some expression that filters the data according to the user's policy>)"
The filters are attached on a table by table basis, so queries like:
SELECT dept.NAME, empl.NAME
FROM
DEPARTMENT dept
INNER JOIN employees empl
are rewritten to
SELECT dept.NAME, empl.NAME
FROM
(SELECT * FROM DEPARTMENT WHERE <FILTER_DEPT>) dept
INNER JOIN (SELECT * FROM employees WHERE <FILTER_EMP>) empl
So far so good, nothing looks bad, but the devil is in the detail
Back to our reporting problem.
Let's say we have a scenario simpler than life, and I associate the user directly to a customer category by adding a CUST_CAT_ID column to the APP_USER table.
I want restrict the user to see only the data associated to its category (category, customers, invoices, invoice item)
So when he writes "select NAME, ADDRESS from customer" the query is rewritten to
"select NAME, ADDRESS from (SELECT * FROM CUSTOMER WHERE (EXISTS SELECT 1 FROM category join app_user on ... where customer.CUST_CAT_ID = app_user.CUST_CAT_ID and app_user.login = get_current_user()))"
where get_current_user is some framework function that gives me the current user.
A little complicated, but nothing too scary.
But when I write something like:
SELECT <relevant columns> FROM category cat JOIN customer cust JOIN invoice inv JOIN invoice_item item WHERE <some filters>
...(query totally legitimate for a sales report), this gets expanded to a scary query that looks like this:
SELECT <relevant columns>
FROM
(SELECT * FROM category WHERE (EXISTS SELECT 1 FROM app_user u WHERE u.CUST_CAT_ID = CAT_ID AND u.login = get_current_user())) cat
JOIN (SELECT * FROM customer WHERE(EXITS SELECT 1 FROM category JOIN app_user WHERE ...)) cust
JOIN (SELECT * FROM invoice WHERE(EXITS SELECT 1 FROM customer JOIN category JOIN app_user WHERE ...)) inv
JOIN (SELECT * FROM invoice_item WHERE(EXITS SELECT 1 FROM invoice JOIN customer JOIN category JOIN app_user WHERE ...)) item
WHERE
<some filters>
Oops! A query with 4 tables is expanded to a 14 tables query, when all I really need is:
SELECT <relevant columns>
FROM category cat JOIN customer cust JOIN invoice inv JOIN invoice_item item
WHERE <some filters> AND (EXISTS SELECT 1 FROM app_user u WHERE u.CUST_CAT_ID = CAT_ID AND u.login = get_current_user())
Let me tell you that we don't use here roles and privileges tables that we must use in a real life scenario.
In a real life scenario we will easily transform the original query in a 20-30 table join (grrrrrrr).
Well, I cannot change the way DBMS_RLS/FGAC works, and also if I choose to use views I cannot write a filtered view for every possible join that a user might create.
All I want is to find out if there is any way to instruct the parser/optimizer, using primary and foreign keys, optimizer parameters hints and other methods, to rewrite the query and eliminate redundant joins.
Of course I can create some materialized views or bitmap join indexes to help me in the process and speed up the query, but using this method in a database that has hundreds of tables can be a little problem in terms of management and performance.

Answer 1

Hello again,
It appeared that, the problem is present only when I try the query in pl/sql developer.
For some reason, even though I set QUERY_REWRITE_INTEGRITY to STALE_TOLERATED, it behaved as this parameter was set to ENFORCED.
So the case was that:
for session - STALE_TOLERATED
for system - ENFORCED
In v$parameter2 against "QUERY_REWRITE_INTEGRITY" was shown "stale_tolerated", but the query was not rewritten.
When I do the same (altering the session and perform the select query) in SQLPlus, everything works as expected - the query is rewritten.
And I conclude the problem is in PL/SQL Developer (my version is 8.0.1.1498) or something related to this.
Edited by: Verdi on 2010-2-12 14:00