OpenEdge supports a separate set of auditing privileges to control who can do what to auditing policies and data. To prevent unauthorized access this information, the compile-time and run-time support for CAN* permissions on database tables and fields have no effect on the auditing metaschema.
Depending on the function of your auditing-aware application, you must ensure that the users who can run it have the appropriate auditing privileges set. The following table lists the auditing privileges and the application functionality that they support.
Table 31. Auditing privilege capabilities
This auditing privilege allows...
This set of capabilities...
Application Audit Event Inserter (Optional)
Generating application events based on active audit policies
Audit Administrator
Configuring audit policies and reading audit data
Audit Data Archiver
Creating, reading, and deleting audit data
Audit Data Reporter
Reading audit policies and data
OpenEdge enforces the Application Audit Event Inserter privilege only if you set the appropriate database auditing option (Enforce Audit Insert Privilege). If you set this option for an audit-enabled database, any user who runs an audit-aware application that generates application events must have the Application Audit Event Inserter privilege, and depending on the application architecture, might also require the Audit Data Reporter privilege. The Audit Administrator and Audit Data Archiver privileges are required by any user who runs an audit configuration and audit archiving tool, respectively. And the Audit Data Reporter privilege is also required for any user who runs an audit reporting tool. For more information on audit privileges, see OpenEdge Getting Started: Core Business Services - Security and Auditing. For more information on setting audit privileges for users, see the Data Administration online help and OpenEdge Development: Basic Database Tools.
