Hi Iudith,

There is a note in this post, stating the following:

“Note: while your Handler can slow down the Select operation, it cannot abort it nor can it change the query being executed. Even when your Handler raises an exception, the query will proceed unhamperedly and return its results.”

So, as I understand from here, raising an exception in an FGA policy handler, as in your proposed workaround, will NOT prevent
the SELECT from executing.

I would be grateful if you could confirm or infirm the correctness of the note above

Well, I can confirm that this is not correct.

Firstly, the documentation clearly states the following:

Function name of the event handler. Include the package name if necessary. This function is invoked only after the first row that matches the audit condition in the query is processed. If the procedure fails with an exception, then the user’s SQL statement fails as well.

Secondly, and more importantly, I have tested it. I ran the following query as user `u2` after creating the policy as described above:

set serveroutput on size unlimited
with
   function spy(
      in_id  in number,
      in_pad in varchar2
   ) return number as
   begin
      dbms_output.put_line('id='
         || in_id
         || ' pad='
         || in_pad);
      return 1;
   end;
select id, pad
  from u1.v
 where id between 1 and 5
   and spy(id, pad) = 1
/

Error starting at line : 2 in command -
with
   function spy(
      in_id  in number,
      in_pad in varchar2
   ) return number as
   begin
      dbms_output.put_line('id='
         || in_id
         || ' pad='
         || in_pad);
      return 1;
   end;
select id, pad
  from u1.v
 where id between 1 and 5
   and spy(id, pad) = 1
Error report -
ORA-28144: Failed to execute fine-grained audit handler
ORA-20942: plsql_declarations are not allowed in the with_clause. See policy SUPPRESS_PLSQL_DELCARATIONS_POLICY for U1.V
ORA-06512: at "U1.SUPPRESS_PLSQL_DELCARATIONS_HANDLER", line 8
ORA-06512: at line 1

The statement was not executed and no results were returned. However, the execution was logged in dba_fga_audit_trail.

I just thought about another possible option that seems to solve the problem, namely, using a NO_MERGE hint in the view definition itself.

Yes, in this simplistic case you can do that. However, IMO this is still a workaround and not a solution. optimizer_secure_view_merging=true should ensure that such predicates are not applied to an intermediate result no matter where the predicate was declared. In the end we do not want to add no_merge hints in every view.

Cheers,
Philipp

Though I don’t have too much practical experience with DBMS_FGA, your post however reminded me of something that I read many years ago,
in a post from Lucas Jellema:

https://technology.amis.nl/it/select-trigger-in-oracle-database-introducing-fine-grained-auditing/

There is a note in this post, stating the following:

“Note: while your Handler can slow down the Select operation, it cannot abort it nor can it change the query being executed. Even when your Handler raises an exception, the query will proceed unhamperedly and return its results.”

So, as I understand from here, raising an exception in an FGA policy handler, as in your proposed workaround, will NOT prevent
the SELECT from executing.

I would be grateful if you could confirm or infirm the correctness of the note above

I just thought about another possible option that seems to solve the problem, namely, using a NO_MERGE hint in the view definition itself.

For your example, this works for both cases, using a stored function or a WITH clause function:

create or replace view v2 as
select /*+ NO_MERGE */ *
from t
where f(class) = 1
/

View created.

select id, pad
from v2
where id between 1 and 5
and spy(id, pad) = 1
/

ID PAD
———————
1 DrMLTDXxxq
4 AszBGEUGEL

2 rows selected.

id=1 pad=DrMLTDXxxq
id=4 pad=AszBGEUGEL

with
function spy(
in_id in number,
in_pad in varchar2
) return number as
begin
dbms_output.put_line(‘id=’
|| in_id
|| ‘ pad=’
|| in_pad);
return 1;
end;
select id, pad
from v2
where id between 1 and 5
and spy(id, pad) = 1;
/

ID PAD
———————-
1 DrMLTDXxxq
4 AszBGEUGEL

id=1 pad=DrMLTDXxxq
id=4 pad=AszBGEUGEL

As a general comment:

Considering the fact that the optimizer might decide in some cases to ignore hints for one reason or another,
using a hint is not always a 100% solution, so, I think that using MERGE VIEW is probably the way to go.
If Oracle already decided to introduce a documented feature that specifically targets this scenario, I don’t think that it is good
to avoid using it because of administrative issues.

Also, I think that Oracle could have implemented this feature also as part of the view definition itself, using a MERGEABLE/NONMERGEABLE
clause, aka the equivalent of an “enforced” hint.
This would make the view not mergeable for ALL users, while the MERGE VIEW privilege may be granted selectively to specific users
or roles.

Cheers & Best Regards,
Iudith Mentzel

Thank you for this eye-opening article!

The plot would thicken a little should the user U2 have the CREATE VIEW privilege, as that would enable to conveniently hide the inline PL/SQL function into a view, thereby circumventing the above FGA policy.

(Granting CREATE VIEW to end users in a context where VPD and/or FGA would be used is probably not a good idea in the first place.)

Regards,