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 through DBMS_MLE). This is achieved by granting access to the procedure or function object of the call specification.

See Also:

Topics

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 through DBMS_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