VPD-Policy function, dependent on CURRENT_SQL

Question

Hello ALL,
i must implement VPD into a medium size data warehouse database, the customer is using 10gR2.
There are some detail tables from which it should be allowed for certain users to retrieve aggregated data, but not to retrieve the details itself.
The background is that everybody in the organization should be able to see the aggregated data for the whole organization, but should have access to the details only for the own organizational unit and units below.
The aggregations are made on the fly. A simple example with the Scott.EMP table would look like this:
- SELECT salary FROM emp -- should be blocked
- SELECt Avg(salary) FROM emp -- shold return the average
I told the customer that this is not possible with VPD - unfortunately they found the SYS_CONTEXT('USERENV''CURRENT_SQL') function and are now asking me to create the policy, based on the current SQL statement... :-(
I consider this as being extremely RISKY, to do so i have to parse the SQL statement to ensure that the aggregation function is used for the protected column, that is not in a comment, and so on...
My questions:
1. Is there another way to achieve such a behavior of a policy function?
2. If not, is there more information available about the current SQL than just the statement as a string? (Access to the builtin SQL parser's tree...)
3. Would you agree that making a policy function based on the SQL statement is a risky thing?
4. Has anybody else ever done this before?
Thank you very much in advance for all answers and your help.
Best regards from Houston,TX
Frank/2
Edited by: fjuedes on Mar 18, 2010 3:41 PM

Answer 1

fjuedes wrote:
Hello ALL,
i must implement VPD into a medium size data warehouse database, the customer is using 10gR2.
There are some detail tables from which it should be allowed for certain users to retrieve aggregated data, but not to retrieve the details itself.
The background is that everybody in the organization should be able to see the aggregated data for the whole organization, but should have access to the details only for the own organizational unit and units below.
The aggregations are made on the fly. A simple example with the Scott.EMP table would look like this:
- SELECT salary FROM emp -- should be blocked
- SELECt Avg(salary) FROM emp -- shold return the average
I told the customer that this is not possible with VPD - unfortunately they found the SYS_CONTEXT('USERENV''CURRENT_SQL') function and are now asking me to create the policy, based on the current SQL statement... :-(
I consider this as being extremely RISKY, to do so i have to parse the SQL statement to ensure that the aggregation function is used for the protected column, that is not in a comment, and so on...
My questions:
1. Is there another way to achieve such a behavior of a policy function?
2. If not, is there more information available about the current SQL than just the statement as a string? (Access to the builtin SQL parser's tree...)
3. Would you agree that making a policy function based on the SQL statement is a risky thing?
4. Has anybody else ever done this before?
Thank you very much in advance for all answers and your help.
Best regards from Houston,TX
Frank/2
Edited by: fjuedes on Mar 18, 2010 3:41 PMThis sounds very much like something a colleague of mine did at a sister organization. I don't have the details (I've asked him to send me the specs as I would like to implement the same thing) but it did involve creating and populating some additional tables to define who had access to which departments, and use info from that table to help build the VPD functions. Another key, though, is that he/we do NOT have the requirement to let people see enterprise-wide aggregation. If user Dilbert is defined as having access only to members of departments 10, 15, and 20, then any aggregates he runs will only include those departments.