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.
MLE distinguishes between dynamic
MLE execution based on
DBMS_MLE, which requires an additional privilege to be granted,
and MLE execution using MLE modules and environments, which does
not.
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 AI 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 AI Database Security Guide for more information about privileges in the Oracle AI Database
Topics
- Necessary Privileges for Dynamic MLE Execution
- 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 Dynamic MLE Execution
Before you can use DBMS_MLE to perform dynamic execution of JavaScript
code, the following object grant must be issued to your user account:
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 AI Database 26ai, 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 AI 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 AI 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 AI 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