Search Results capture_privilege_use

Overview

SYS.DBMS_PRIV_CAPTURE is an Oracle Database-supplied PL/SQL package that underpins privilege analysis, the mechanism by which the database records the system privileges, object privileges, and roles that are actually exercised during the execution of PL/SQL and Java code. The package is owned by SYS and is declared with AUTHID CURRENT_USER, meaning its internal privilege checks execute with the rights of the calling user rather than the package owner. Within an Oracle E-Business Suite 12.1.1 or 12.2.2 environment, this package is not an EBS application API in the conventional sense; it is a kernel component surfaced through the EBS data dictionary and referenced extensively by the APPS schema. Its principal business value is security auditing and least-privilege analysis: administrators can determine precisely which privileges an application identity requires before revoking unused grants, a task of particular relevance to the tightly controlled APPS and SYSADMIN accounts in EBS.

Key Procedures and Functions

The package exposes sixteen documented program units, of which the CAPTURE_PRIVILEGE_USE procedure — the object returned by the search term — is the central entry point. Two overloaded variants exist:

• CAPTURE_PRIVILEGE_USE (numeric variant) — Records a privilege usage when the configured privilege capture conditions are satisfied. It accepts identifiers for the user holding the privilege, the system privilege, the role name, the object privilege, the accessed object, and the security domain represented both as role identifiers and as role names.
• CAPTURE_PRIVILEGE_USE (string variant) — Performs the identical capture operation but accepts user, privilege, owner, and object names as strings for caller convenience, together with the same domain and domain-name arrays. This overload is the form most commonly invoked from diagnosing sessions.
• HAS_SYS_PRIV_DIRECT, HAS_SYS_PRIV_DIRECT_ID, HAS_SYS_PRIV, HAS_SYS_PRIV_ID — Determine whether the effective user holds a given system privilege, either directly or through the full privilege domain, in name or identifier form.
• HAS_OBJ_PRIV_DIRECT, HAS_OBJ_PRIV_DIRECT_ID, HAS_OBJ_PRIV, HAS_OBJ_PRIV_ID — Equivalent checks for object privileges.
• HAS_ROLE_PRIV_DIRECT, HAS_ROLE_PRIV_DIRECT_ID, HAS_ROLE_PRIV, HAS_ROLE_PRIV_ID — Equivalent checks for role membership and enablement.
• SES_HAS_SYS_PRIV and SES_HAS_ROLE_PRIV — Session-scoped variants that report whether the current session possesses a system privilege or role.

Tables Accessed

The ETRM metadata lists no application tables referenced through APPS synonyms. This is consistent with the package's design: it operates against Oracle's own privilege-analysis dictionary infrastructure rather than EBS business tables. The captured results are surfaced through database views such as DBA_PRIV_CAPTURES, DBA_USED_PRIVS, and DBA_UNUSED_PRIVS, which administrators query to audit privilege consumption. Because the package writes to the underlying capture repository only when an active privilege capture has been created, its footprint in an EBS database is limited to periods of deliberate auditing.

Usage Notes

DBMS_PRIV_CAPTURE is normally driven by the database itself rather than by EBS forms or concurrent programs. When a privilege capture is enabled with DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE, the kernel invokes CAPTURE_PRIVILEGE_USE automatically as privileged operations execute in PL/SQL and Java. The HAS_* family is available to diagnostic scripts, custom auditing code, and support engagements that must verify whether a runtime identity truly holds a privilege directly or only through role activation. In EBS 12.1.1 and 12.2.2, this capability is most often employed when reviewing the extensive grants held by APPS, validating the impact of planned revocation, or investigating security findings. The package is referenced by twenty-six other packages, confirming its role as foundational infrastructure; direct invocation by application code should be reserved for well-controlled diagnostic scenarios, and capture should be disabled promptly once analysis concludes to avoid unnecessary overhead and repository growth.