System and Object Privileges Required for Working with JavaScript in MLE
Depending on the project's requirements, different privileges can be granted to users and or roles, allowing them to interact with JavaScript in the database.
Administrators should review application requirements carefully and only grant the minimum number of privileges necessary to users. This is especially true for system privileges, which are very powerful and should only be granted to trusted users.
The minimum privilege required to work with MLE JavaScript code is the right to execute JavaScript code in the
database. MLE distinguishes between dynamic
MLE execution based on
DBMS_MLE
and MLE
execution using MLE modules and
environments.
Creating stored code in JavaScript requires additional privileges to create JavaScript schema objects in your own schema.
The most powerful privileges available in MLE
allow super-users to create, alter, and drop MLE schema objects in any schema, not just their own. As with all
privileges in Oracle Database, those with ANY
in their name are
most powerful and should only be granted to trusted users if deemed absolutely
necessary.
Note:
Object privileges on modules and environments do not grant access to an application, for example, the combination of source code and user context defined by a call specification (or throughDBMS_MLE
). This is achieved by granting access to the procedure
or function object of the call specification.
See Also:
-
Necessary Privileges for Creating MLE Modules and Environments in ANY Schema for more about handling system privileges
-
Oracle Database Security Guide for more information about privileges in the Oracle Database
Topics
- Necessary Privileges for the Execution of JavaScript Code
- Necessary Privileges for Using the NoSQL API
- Necessary Privileges for Creating MLE Schema Objects
- Necessary Privileges for Creating MLE Modules and Environments in ANY Schema
- Necessary Privileges for Post-Execution Debugging
Parent topic: MLE Security
Necessary Privileges for the Execution of JavaScript Code
Before you can execute any JavaScript code in your own schema, the following object grant must have been issued to your user account:
GRANT EXECUTE ON JAVASCRIPT TO <role | user>
The EXECUTE ON JAVASCRIPT
privilege does not include dynamic execution
of JavaScript using DBMS_MLE
. If you wish to make use of
DBMS_MLE
, an additional privilege is required:
GRANT EXECUTE DYNAMIC MLE TO <role | user>
Necessary Privileges for Using the NoSQL API
In cases where MLE JavaScript code references
the Simple Oracle Document Access (SODA), the SODA_APP
role must be
granted to the user or role:
GRANT SODA_APP <role | user>
Necessary Privileges for Creating MLE Schema Objects
If you wish to create MLE modules and environments in your own schema, further system privileges are required:
GRANT CREATE MLE TO <role | user>
In case any MLE module is to be exposed to the database's SQL and PL/SQL layers in the form of call specifications, you also require the right to create PL/SQL procedures:
GRANT CREATE PROCEDURE TO <role | user>
It is highly likely that you will require further system privileges,
depending on your use case, to create additional schema objects such as tables,
indexes, and sequences. Beginning with Oracle Database 23ai, the
DB_DEVELOPER_ROLE
role allows administrators to grant the
necessary privileges to developers in their local development databases quickly. The
role can be granted as shown in the following snippet:
GRANT DB_DEVELOPER_ROLE TO <role | user>
See Also:
Oracle Database Security
Guide for
more information about the DB_DEVELOPER_ROLE
role
Necessary Privileges for Creating MLE Modules and Environments in ANY Schema
Additional privileges can be granted to power users and administrators, allowing them to create, alter, and drop MLE schema objects in any schema.
GRANT CREATE ANY MLE TO <role | user>
GRANT DROP ANY MLE TO <role | user>
GRANT ALTER ANY MLE TO <role | user>
As with all privileges in Oracle Databases featuring ANY
in their
name, these are very powerful and should only be granted after a thorough
investigation to trusted users. For this reason, only the DBA
role
and the SYS
account have been granted these privileges. The use of
these system privileges is audited by the ORA_SECURECONFIG
audit
policy.
To create MLE call specifications in schemas
other than your own requires the right to CREATE ANY PROCEDURE
to
be granted as well:
GRANT CREATE ANY PROCEDURE TO <role | user>
Just like the previously listed system privileges, CREATE ANY
PROCEDURE
is audited by the same audit policy,
ORA_SECURECONFIG
.
See Also:
Oracle Database Security
Guide for
more information about the ORA_SECURECONFIG
audit policy
Necessary Privileges for Post-Execution Debugging
It is possible to allow other database users to collect debug information for MLE modules they don't own. By default, MLE owners can use post-execution debugging on their own MLE modules without specific grants. It is possible to grant the ability to collect debug information to a different role or user, allowing them to use post-execution debugging of JavaScript code on your behalf as the module owner:
GRANT COLLECT DEBUG INFO ON <module> TO <role | user>
Note:
You can elect to grant the execute privilege on MLE module calls created as PL/SQL code with definer's rights to users in other schemas. In this case, there is no need to grant other users any additional privileges.Note:
Object privileges on modules and environments do not grant access to an application, for example, the combination of source code and user context defined by a call specification (or throughDBMS_MLE
). This is achieved by
granting access to the procedure or function object of the call
specification.
See Also:
Post-Execution Debugging of MLE JavaScript Modules for more information on post-execution debugging