Querying CDB_* Views Generates Audit Records Mustafa, 2023-10-04 Hi, I would like to share a small problem I had on one of my databases. I had a common user on my CDBs to manage the databases (version is 19.20). On my databases, I use unified auditing and traditional audit is off. ORA_LOGON_FAILURES and ORA_SECURECONFIG policies are only enabled policies. There are two pdbs on the cdb. Problem is, for this common user, querying any CDB_* view in a procedure (including functions/packages etc) generates audit records. for example when I run “select * from cdb_objects” no audit records are generated but if I use it in a simple plsql object like this: Oracle PL/SQL create or replace procedure sp_X as begin for i in (select * from cdb_objects) loop null; end loop; end; / 1234567 create or replace procedure sp_X as begin for i in (select * from cdb_objects) loop null; end loop;end;/ Running this procedure generates audit records. For the procedure above, two audit records are generated one for DBA_OBJECTS and the other is CDB_OBJECTS. DBA_OBJECTS is the first one generated. When I checked the audit records (unified_audit_trail) I realized that, audit generator policy was ORA_SECURECONFIG and record for “DBA_*” view has “EXEMPT ACCESS POLICY” on system_privileged_used column. this privilege is commonly used for export entire data even if there is an active virtual private database policies. So for some reason, oracle says, my common user is using EXEMPT ACCESS POLICY privilege to access on the PDB. Here are interesting points: This common user has DBA privilege on all pdbs and root, also has direct select privilege on DBA_OBJECTS view on all pdbs and root as well. there is no any VPD or label security etc. I believe there is no reason to use EXEMPT ACCESS POLICY privilege while querying DBA_* view on pdb via CDB_* view. There are two pdbs on the cdb but only one of the pdb cause this audit generation. how do I know that? on the original code, there are some plsql variables and one of them is CON_ID. Unified_Audit_Trail has “sql_binds” column that shows con_id and it always shows same con_id. This happens on all CDB_* views. This database is copied from another database and there few more copied databases as this one and they have quite same structure. same common user, same privileges, same codes etc and non of them has this problem. if I create a view like “create or replace view v_objects as select * from containers(dba_objects)” and use that view in the code instead of cdb_objects, it does not generate any audit record. if you check CDB_* views query, they are mostly the same with the view I just mentioned. they all use CONTAINERS(DBA_*) clause but somehow, my view doesn’t cause this problem. So I dig as much as I could but couldn’t find the root problem here. Only thing I come up with is, this pdb has been converted from non-cdb, maybe conversion had some problems but not sure. After trying many things, I created a new common user and grant same privileges then check the audit. There weren’t any! so this is specific to my common user and one specific pdb. I can start an SR and talked to support team for a while but since I have a workaround (creating a view with containers clause), I wanted to do whatever I can do first and my last option was a “kill switch”. I exported everything the user has and drop the user. then recreate with my create scripts, grant privileges, import the objects again. Problem is gone. I believe there was a glitch (maybe a small bug) but at least I get rid of unnecessary thousands of audit records in the end. Thanks for reading. 19c Administration Multi-tenant auditcdbEXEMPT ACCESS POLICYunified audit