Oracle8i Java Developer's Guide Release 3 (8.1.7) Part Number A83728-01 |
Library | Service | Contents | Index

## Database Contents and JVM Security

Once you are connected to the database, you still must have the correct Java 2 Permissions and database privileges to access the resources stored within the database. These resources include the following:

- database resources, such as tables and PL/SQL packages

- operating system resources, such as files and sockets

- Aurora JVM classes

- user-loaded classes

These resources can be protected by the following two methods:

Resource Security | Description
--- | ---
Database Resource Security | Authorization for database resources requires that database privileges (not the same as the Java 2 security permissions) are granted to resources. For example, database resources include tables, classes, or PL/SQL packages. For more information, see the Oracle8i Application Developer's Guide - Fundamentals. All user-defined classes are secured against users from other schemas. You can grant execution permission to other users/schemas through an option on the `loadjava` command. For more information on setting execution rights when loading the class, see the -`grant` option discussed in "Loading Classes" or the Oracle8i Java Tools Reference for complete information on loadjava.
JVM Security | JServer uses Java 2 security, which uses Permission objects to protect operating system resources. Java 2 security is automatically installed upon startup and protects all operating system resources and JVM classes from all users, except JAVA_ADMIN. JAVA_ADMIN can grant permission to other users to access these classes. See "Java 2 Security" for how to manage and modify Java 2 Permissions and policies.

### Java 2 Security

Each user or schema must be assigned the proper permissions to access operating system resources. For example, this includes sockets, files, and system properties.

Java 2 security was created to provide a flexible, configurable security for Java applications. With Java 2 security, you can define exactly what permissions on each loaded object a schema or role will have. In 8.1.5, the security provided you the choice of two secure roles:

- `JAVAUSERPRIV`--few Permissions, including examining properties

- `JAVASYSPRIV`--major Permissions, including updating JVM protected packages

  Note: Both roles still exist within 8.1.6 for backward compatibility; however, Oracle recommends that you specify each Permission explicitly, rather than utilize these roles.

Because JServer security is based on Java 2 security, you assign Permissions on a class by class basis. Permissions contains two string attributes:

- target (name) attribute

- action attribute

These permissions are assigned through database management tools. Each permission is encapsulated in a Permission object and is stored within a Permission table. The methods for managing all permissions are the subject for most of this chapter.

Java security was created for the non-database world. When you apply the Java 2 security model within the database, certain differences manifest themselves. For example, Java 2 security defines that all applets are implicitly untrusted and all classes within the CLASSPATH are trusted. Within Oracle8i, all classes are loaded within a secure database; thus, no classes are trusted.

The following table briefly describes the differences between Sun Microsystem's Java 2 security and Oracle8i's implementation. This table assumes that you already understand Sun Microsystem's Java 2 security model. For more information, we recommend the following books:

- Inside Java 2 Platform Security by Li Gong

- Java Security by Scott Oaks

  Java 2 Security standard | Oracle8i implementation
  --- | ---
  Java classes located within the CLASSPATH are trusted. | All Java classes are loaded within the database. Classes are trusted on a class by class basis according to the Permission granted.
  You can specify the policy through the -`usepolicy` flag on the `java` command line. | You must specify the policy within the `PolicyTable`.
  You can write your own SecurityManager or use the Launcher. | You can write your own SecurityManager; Oracle recommends that you use only Aurora's SecurityManager or that you extend Aurora's SecurityManager. If you want to modify the behavior, you should not define a SecurityManager; instead, you should extend oracle.aurora.rdbms.SecurityManagerImpl and override specific methods.
  SecurityManager is not initialized for you. You must initialize the SecurityManager. | Aurora always initializes SecurityManager at startup.
  Permissions are determined by the location where the application or applet is loaded from (the URL) or keycode (signed code). | Permissions are determined by the schema in which the class is loaded. JServer does not support signed code.
  The security policy is defined in a file. | The PolicyTable definition is contained within a secure database table.
  You can update the security policy file through a text editor (if you have the correct Permissions) or through a tool. | You update the PolicyTable through DBMS_JAVA procedures. After initialization, only JAVA_ADMIN has permission to modify the PolicyTable. JAVA_ADMIN must grant you the right to modify the PolicyTable for you to grant Permissions to others.
  Permissions are assigned to a protection domain, which classes can belong to. | All classes within the same schema are within the same protection domain.
  Use `CodeSource` class for identifying code. The `equals` method returns true if the URL and certificates are equal. The `implies` method returns true if the first CodeSource is a generic representation that includes the specific `CodeSource` object. | Use `CodeSource` class for identifying schema. The `equals` method returns true if the schemas are the same. The `implies` method returns true if the schemas are the same.
  Supports positive Permissions only (grant). | Supports both positive (grant) and limitation (restrict) Permissions.

### Setting Permissions

As designed in Java 2 security, Oracle8i supports the security classes. Normally, you set the Permissions for the code base either through a tool or by editing the security policy file. In Oracle8i, you set the Permissions dynamically through DBMS_JAVA procedures. These procedures modify a policy table, which is a new table within the database that exclusively manages Java 2 security Permissions.

Two views have been created for you to view the policy table: USER_JAVA_POLICY and DBA_JAVA_POLICY. Both views contain information about granted and limitation Permissions. The DBA_JAVA_POLICY view can see all rows within the policy table; the USER_JAVA_POLICY table can only see Permissions relevant to the current user. The following is a description of the rows within each view:

Table Column | Description
--- | ---
Kind | GRANT or RESTRICT. Shows whether this Permission is a positive (GRANT) or a limitation (RESTRICT) Permission.
Grantee | The name of the user, schema, or role that the Permission object is assigned to.
Permission_schema | The schema that the Permission object is loaded into.
Permission_type | The Permission class type, which is designated by a string containing the full class name, such as, `java.io.FilePermission.`
Permission_name | The target attribute (name) of the Permission object. You use this name when defining the Permission. When defining the target for a Permission of type PolicyTablePermission, the name can become quite complicated. See "Acquiring Administrative Permission to Update Policy Table" for more information.
Permission_action | The action attribute for this Permission. Many Permissions expect a null value if no action is appropriate for the Permission.
Status | ACTIVE or INACTIVE. After creating a row for a Permission, you can disable or re-enable it. This column shows the status of whether the Permission is enabled (ACTIVE) or disabled (INACTIVE).
Key | Sequence number you use to identify this row. This number should be supplied when disabling, enabling, or deleting the Permission.

There are two ways to set your Permissions:

- Fine-Grain Definition for Each Permission--You grant each Permission individually for specific users or roles. If you do not grant a Permission for access, the schema will be denied access.

- General Permission Definition Assigned to Roles--If you do not want to grant specific Permissions for each user, you can grant roles, which grants a collection of Permissions to the user. Oracle8i supplies the roles: JAVAUSERPRIV or JAVASYSPRIV.

  Note: For absolute certainty about your security, you should implement the fine-grain definition. The general definition is easier; but you might not get the exact security you require.

#### Fine-Grain Definition for Each Permission

To set individual Permissions within the policy table, you must provide the following information:

Parameter | Description
--- | ---
Grantee | The name of the user, schema, or role that you want the grant to apply to. PUBLIC specifies that the row applies to all users.
Permission type | The Permission class that you are granting Permission on. For example, if you are defining access to a file, the Permission type would be `FilePermission`. This parameter requires a fully-qualified name of a class that extends `java.lang.security.Permission`. If the class is not within SYS, the name should be prefixed by <schema>:. For example, `mySchema:myPackage.MyPermission` is a valid name for a user generated Permission.
Permission name | The meaning of the target attribute is defined by the Permission class. Examine the appropriate Permission class for the relevant name.
Permission action | The type of actions that you can specify vary according to the Permission type. For example, `FilePermission` can have the actions of read or write.
Key | Number returned from grant or limit to use on enable, disable, or delete methods.

You can grant either Java 2 Permissions or create your own. The Java 2 Permissions are listed in Table 5-1. If you would like to create your own Permissions, see "Creating Permissions".

##### Table 5-1 Permission Types

`java.util.PropertyPermission`
`java.io.SerializablePermission`
`java.io.FilePermission`
`java.net.NetPermission`
`java.net.SocketPermission`
`java.lang.RuntimePermission`
`java.lang.reflect.ReflectPermission`
`java.security.SecurityPermission`
`oracle.aurora.rdbms.security.PolicyTablePermission`
`oracle.aurora.security.JServerPermission`

You can grant permissions using either SQL or Java, as shown below. However, each returns a row key identifier that identifies the row within the permission table. In the Java version of `DBMS_JAVA`, each method returns the row key identifier, either as a returned parameter or as an OUT variable in the parameter list. In the PL/SQL `DBMS_JAVA` package, the row key is returned only in the procedure that defines the `key` `OUT` parameter. This key is used to enable and disable specific Permissions. See "Enabling or Disabling Permissions" for more information.

If, after executing the grant, a row already exists for the exact Permission, no update occurs, but the key for that row is returned. If the row was disabled, executing the grant enables the existing row.

Note: If granting `FilePermission`, you must provide the physical name of the directory or file, such as `/private/oracle`. You cannot provide either an environment variable, such as $ORACLE_HOME, or a symbolic link. Also, to denote all files within a directory, provide the '*' symbol, as follows: '`/private/oracle/*`'. To denote all directories and files within a directory, provide the '-' symbol, as follows: '`/private/oracle/-`'.

Granting Permissions using the DBMS_JAVA package:

    procedure grant_permission( grantee varchar2, permission_type varchar2,

    	permission_name varchar2,

    	permission_action varchar2 )

    procedure grant_permission( grantee varchar2, permission_type varchar2,

    	permission_name varchar2,

    	permission_action varchar2, key OUT number)

Granting Permissions using Java:

    long oracle.aurora.rdbms.security.PolicyTableManager.grant(

    	java.lang.String grantee,

    	java.lang.String permission_type,

    	java.lang.String permission_name,

    	java.lang.String permission_action);

    void oracle.aurora.rdbms.security.PolicyTableManager.grant(

    	java.lang.String grantee,

    	java.lang.String permission_type,

    	java.lang.String permission_name,

    	java.lang.String permission_action,

    	long[] key);

Limiting Permissions using the DBMS_JAVA package:

    procedure restrict_permission( grantee varchar2, permission_type varchar2,

    	permission_name varchar2,

    	permission_action varchar2)

    procedure restrict_permission( grantee varchar2, permission_type varchar2,

    	permission_name varchar2,

    	permission_action varchar2, key OUT number)

Limiting Permissions using Java:

    long oracle.aurora.rdbms.security.PolicyTableManager.restrict(

    	java.lang.String grantee,

    	java.lang.String permission_type,

    	java.lang.String permission_name,

    	java.lang.String permission_action);

    void oracle.aurora.rdbms.security.PolicyTableManager.restrict(

    	java.lang.String grantee,

    	java.lang.String permission_type,

    	java.lang.String permission_name,

    	java.lang.String permission_action,

    	long[] key);

#### Example 5-1 Granting Permissions

Assuming that you have appropriate Permissions to modify the policy table, you use the `grant_permission` method within the DBMS_JAVA package to modify the PolicyTable to allow the user access to the indicated file. In this example, the user, Larry, has `PolicyTable` modification `Permission`. Within a SQL package, Larry grants permission to read and write a file to the user Dave.

    connect larry/larry

    REM Grant DAVE permission to read and write the Test1 file.
    call dbms_java.grant_permission('DAVE',

    	'java.io.FilePermission', '/test/Test1',

    	'read,write');

    REM commit the changes to the PolicyTable
    commit;

#### Example 5-2 Limiting Permissions

You use the `restrict` method for specifying a limitation or exception for general rules. A general rule is a rule where, in most cases, the Permission is true. However, there may be exceptions to this rule. For these exceptions, you specify a limitation Permission.

That is, if you have defined a general rule that no one can read or write for an entire directory, you can define a limitation on an aspect of this rule through the `restrict` method. For example, if you want to allow access to all files within the `/tmp` directory--except for your `password` file that exists in that directory--you would grant permission for read and write to all files within `/tmp` and limit read and write access to the `password` file.

If you want to specify an exception to the limitation, you would create an explicit grant Permission to override the limitation Permission. In the scenario mentioned above, if you want the file owner to still be able to modify the `password` file, you can grant a more explicit Permission to allow access to one user, which will override the limitation. JServer security combines all rules to understand who really has access to the `password` file. This is demonstrated in the following diagram:

The explicit rule is as follows:

  If the limitation Permission implies the request, then for a grant to be effective, the limitation Permission must also imply the grant.

The following is the code that implements this example:

1. Grant everyone (PUBLIC) read and write permission to all files in /`tmp`.

2. Limit everyone (PUBLIC) from reading or writing one file in /`tmp`/`password`.

3. Grant Larry (owner) explicit permission to read and write the `password` file.

       connect larry/larry

       REM Grant permission to all users (PUBLIC) to be able to read and write

       REM all files in /tmp.
       call dbms_java.grant_permission('PUBLIC',

       	'java.io.FilePermission',

       	'/tmp/*',

       	'read,write');

       REM Limit permission to all users (PUBLIC) from reading or writing the
       REM password file in /tmp.
       call dbms_java.restrict_permission('PUBLIC',

       	'java.io.FilePermission',

       	'/tmp/password',

       	'read,write');

       REM By providing a more specific rule that overrides the limitation,
       REM Larry can read and write /tmp/password.
       call dbms_java.grant_permission('LARRY',

       	'java.io.FilePermission',

       	'/tmp/password',

       	'read,write');
       commit;

#### Acquiring Administrative Permission to Update Policy Table

All Permissions are rows within the policy table. As it is a table within the database and thus a resource, permission is needed to modify it. Specifically, the `PolicyTablePermission` object is required to modify the table. After the first initialization for JServer, only a single role--JAVA_ADMIN--is granted the `PolicyTablePermission` to modify the policy table. The JAVA_ADMIN role is immediately assigned to DBA; thus, if you are assigned to the DBA group, you will automatically take on all JAVA_ADMIN Permissions.

In order for you to be able to add Permissions as rows to this table, JAVA_ADMIN must grant your schema update rights for the `PolicyTablePermission`. This Permission defines that your schema can add rows to the table. Each PolicyTablePermission is for a specific Permission type. For example, in order for you to add a Permission that controls access to a file, you must have a `PolicyTablePermission` that allows you to grant or limit a Permission on a `FilePermission`. Once this occurs, you have administrative Permission for FilePermission.

The administrator could grant and limit the `PolicyTablePermissions` in the same manner as other Permissions, but the syntax is complicated. For ease of use, use one of the following methods within the DBMS_JAVA package to grant administrative Permissions.

Granting policy table administrative Permissions using DBMS_JAVA:

    procedure grant_policy_permission( grantee varchar2, permission_schema varchar2,
    	permission_type varchar2,

    	permission_name varchar2)

    procedure grant_policy_permission( grantee varchar2, permission_schema varchar2,
    	permission_type varchar2,

    	permission_name varchar2,

    	key OUT number)

Granting policy table administrative permission using Java:

    long oracle.aurora.rdbms.security.PolicyTableManager.grantPolicyPermission(

    	java.lang.String grantee,

    	java.lang.String permission_type,

    	java.lang.String permission_name);

    void oracle.aurora.rdbms.security.PolicyTableManager.grantPolicyPermission(

    	java.lang.String grantee,

    	java.lang.String permission_type,

    	java.lang.String permission_name,

    	long[] key);

Parameter | Description
--- | ---
Grantee | The name of the user, schema, or role that you want the grant to apply to. PUBLIC specifies that the row applies to all users.
Permission_schema | The <`schema`> where the Permission class is loaded.
Permission_type | The Permission class that you are granting Permission on. For example, if you are defining access to a file, the Permission type would be `FilePermission`. This parameter requires a fully-qualified name of a class that extends `java.lang.security.Permission`. If the class is not within SYS, the name should be prefixed by <schema>:. For example, `mySchema:myPackage.MyPermission` is a valid name for a user generated Permission.
Permission_name | The meaning of the target attribute is defined by the Permission class. Examine the appropriate Permission class for the relevant name.
Row_ number | Number returned from grant or limitation to use on enable, disable, or delete methods.

Note: When looking at the policy table, the name within the PolicyTablePermission rows contains both the Permission type and the Permission name, which are separated by a '#'. For example, to grant a user administrative rights for reading a file, the name in the row contains `java.io.FilePermission#read`. The '#' separates the Permission class from the Permission name.

#### Example 5-3 Granting PolicyTable Permission

The following example shows JAVA_ADMIN (as SYS) giving Larry permission to update the PolicyTable for `FilePermission`. Once this Permission is granted, Larry can grant permissions to other users for reading, writing, and deleting files.

    REM Connect as SYS, which is assigned JAVA_ADMIN role, to give Larry permission

    REM to modify the PolicyTable
    connect SYS/SYS as SYSDBA

    REM SYS grants Larry the right to administer permissions for
    REM FilePermission
    call dbms_java.grant_policy_permission('LARRY', 'SYS',

    	'java.io.FilePermission', '*');

#### Creating Permissions

You can create your own Permission type by performing the following:

1. Create and load the user Permission.

2. Grant administrative and action Permissions to specified users.

3. Implement security checks using the Permission.

##### 1. Create and load the user Permission

You can create your own Permission by extending the Java 2 Permission class. Any user created Permission must extend `Permission`. The following example creates `MyPermission`. `MyPermission` extends `BasicPermission`, which in turn extends `Permission`.

    package test.larry;
    import java.security.Permission;
    import java.security.BasicPermission;

    public class MyPermission extends BasicPermission {

      public MyPermission(String name) {
        super(name);
      }

      public boolean implies(Permission p) {
        boolean result = super.implies(p);
        return result;
      }
    }

##### 2. Grant administrative and action Permissions to specified users

When you create a Permission, you are designated as owner of that Permission. The owner is implicitly granted administrative Permission. This means that the owner can be an administrator for this Permission and can execute `grant_policy_permission`. Administrative Permission permits the user to update the policy table for the user-defined Permission.

For example, if LARRY creates a Permission, `MyPermission`, only LARRY can invoke `grant_policy_permission` for himself or another user. This method updates the `PolicyTable` on who can grant rights to `MyPermission`. The following code demonstrates this:

    REM Since Larry is the user that owns MyPermission, Larry connects to
    REW the database to assign permissions for MyPermission.
    connect larry/larry

    REM As the owner of MyPermission, Larry grants himself the right to
    REM administer permissions for test.larry.MyPermission within the JVM
    REM security PolicyTable. Only the owner of the user-defined permission
    REM can grant administrative rights.
    call dbms_java.grant_policy_permission('LARRY', 'LARRY',

    	 'test.larry.MyPermission', '*');

    REM commit the changes to the PolicyTable
    commit;

Once you have granted administrative rights, you can grant action Permissions for the user created Permission. For example, the following SQL grants permission for LARRY to execute anything within `MyPermission` and DAVE to be able to only execute actions that start with "act.".

    REM Since Larry is the user that creates MyPermission, Larry connects to
    REW the database to assign permissions for MyPermission.
    connect larry/larry

    REM Once able to modify the PolicyTable for MyPermission, Larry grants himself
    REM full permission for MyPermission. Notice that the Permission is prepended
    REM with its owner schema.
    call dbms_java.grant_permission( 'LARRY',

    	'LARRY:test.larry.MyPermission', '*', null);

    REM Larry grants Dave permission to do any actions that start with 'act.*'.
    call dbms_java.grant_permission
            ('DAVE', 'LARRY:test.larry.MyPermission', 'act.*', null);

    REM commit the changes to the PolicyTable
    commit;

##### 3. Implement security checks using the Permission

Once you have created, loaded, and assigned Permissions for `MyPermission`, you must implement the call to SecurityManager for having the Permission checked. There are four methods in the following example: `sensitive`, `act`, `print`, and `hello`. Because of the Permissions granted in the SQL example in step 2, the following users can execute methods within the example class:

- LARRY can execute any of the methods.

- DAVE is given permission to execute only the `act` method.

- Anyone can execute the `print` and `hello` methods. The `print` method does not check any Permissions, so anyone can execute the `print` method. The `hello` method executes `AccessController.doPrivileged`, which means that the method executes with LARRY's Permissions. This is referred to as definer's rights.

      package test.larry;
      import java.security.AccessController;
      import java.security.Permission;
      import java.security.PrivilegedAction;

      import java.sql.Connection;
      import java.sql.SQLException;

      /**
       * MyActions is a class with a variety of public methods that
       * have some security risks associated with them. We will rely
       * on the Java security mechanisms to ensure that they are
       * performed only by code that is authorized to do so.
       */

      public class Larry {

        private static String secret = "Larry's secret";

        MyPermission sensitivePermission = new MyPermission("sensitive");

        /**
         * This is a security sensitive operation. That is it can
         * compromise our security if it is executed by a "bad guy".
         * Only larry has permission to execute sensitive.
         */
        public void sensitive() {
          checkPermission(sensitivePermission);
          print();
        }

        /**
         * Will print a message from Larry.  We need to be
         * careful about who is allowed to do this
         * because messages from Larry may have extra impact.
         * Both larry and dave have permission to execute act.
         */
      public void act(String message) {
          MyPermission p = new MyPermission("act." + message);
          checkPermission(p);
          System.out.println("Larry says: " + message);
        }

        /**
         * Print our secret key
         * No permission check is made; anyone can execute print.
         */
        private void print() {
          System.out.println(secret);
        }

        /**
         * Print "Hello"
         * This method invokes doPrivileged, which makes the method run
         * under definer's rights. So, this method runs under Larry's
         * rights, so anyone can execute hello.
         * Only Larry can execute hello
         */
        public void hello() {
          AccessController.doPrivileged(new PrivilegedAction() {
            public Object run() { act("hello"); return null; }
      });
        }

        /**
         * If a security manager is installed ask it to check permission
         * otherwise use the AccessController directly
         */
        void checkPermission(Permission permission) {
          SecurityManager sm = System.getSecurityManager();
          sm.checkPermission(permission);
        }
      }

#### Enabling or Disabling Permissions

Once you have created a row that defines a Permission, you can disable it so that it is no longer applied. However, if you decide you want the row action again, you can enable the row. You can delete the row from the table if you believe that it will never be used again. To delete, you must first disable the row. If you do not disable the row, the deletion will not occur.

To disable rows, you can use either the `disable_permission` or the `revoke` method.

- The `revoke_permission` method takes in parameters similar to the `grant` and `restrict` methods. It searches the entire policy table for all rows that match the supplied parameters.

- The `disable_permission` method disables only a single row within the policy table. To do this, it takes in the policy table key. This key is also necessary to enable or delete a Permission. To retrieve the Permission key number, perform one of the following:

  - Save the key when it is returned on the grant or limit calls. If you do not foresee a need to ever enable or disable the Permission, you can use the grant and limit calls that do not return the Permission number.

  - View DBA_JAVA_POLICY or USER_JAVA_POLICY for the appropriate Permission key number.

Disabling Permissions using DBMS_JAVA:

    procedure revoke_permission(permission_schema varchar2,
    	permission_type varchar2,

    	permission_name varchar2,

    	permission_action varchar2)

    procedure disable_permission(key number)

Disabling Permissions using Java:

    void revoke(String schema, String type, String name, String action);

    void oracle.aurora.rdbms.security.PolicyTableManager.disable(long number);

Enabling Permissions using DBMS_JAVA:

    procedure enable_permission(key number)

Enabling Permissions using Java:

    void oracle.aurora.rdbms.security.PolicyTableManager.enable(long number);

Deleting Permissions using DBMS_JAVA:

    procedure delete_permission(key number)

Deleting Permissions using Java:

    void oracle.aurora.rdbms.security.PolicyTableManager.delete(long number);

#### Permission Types

Table 5-2 lists the installed Permission types. Whenever you want to grant or limit a Permission, you must provide the Permission type within the DBMS_JAVA method. The Permission types with which you control access are the following:

- Oracle-provided Permission types listed in Table 5-2

- user created Permission types that extend `java.security.Permission`

  ##### Table 5-2 Permission Types

  `java.util.PropertyPermission`
  `java.io.SerializablePermission`
  `java.io.FilePermission`
  `java.net.NetPermission`
  `java.net.SocketPermission`
  `java.lang.RuntimePermission`
  `java.lang.reflect.ReflectPermission`
  `java.security.SecurityPermission`
  `oracle.aurora.rdbms.security.PolicyTablePermission`
  `oracle.aurora.security.JServerPermission`

All the Java Permission types are documented in Sun Microsystem's Java 2 documentation.

Note: SYS is granted permission to load libraries that come with Oracle. However, Aurora does not support other users loading libraries, because loading C within the database is insecure. So, you are not allowed to grant permission for `loadLibrary.*` of `RuntimePermission`.

The Oracle-specific Permissions, `PolicyTablePermission` and `JServerPermission` are described below:

##### oracle.aurora.rdbms.security.PolicyTablePermission

This Permission controls who can update the policy table. Once granted the right to update the policy table for a certain `Permission` type, the user can control other user's access to some resource.

After JServer initialization, only the JAVA_ADMIN role can grant administrative rights for the policy table through `PolicyTablePermission`. Once it grants this right to other users, these users can in turn update the policy table with their own grant and limitation Permissions.

To grant policy table updates, you use the DBMS_JAVA method: `grant_policy_permission`, as discussed in "Acquiring Administrative Permission to Update Policy Table". Once you have updated the table, you can view either the DBA_JAVA_POLICY or USER_JAVA_POLICY views to see who has been granted Permissions.

##### oracle.aurora.security.JServerPermission

You use this Permission to grant and limit access to Aurora JVM resources. The `JServerPermission` extends from `BasicPermission`. The following table lists the names that `JServerPermission` grants access for:

Permission Name | Description
--- | ---
LoadClassInPackage.<package_name> | grants the ability to load a class within the specified package
Verifier | grants the ability to turn the bytecode verifier on or off
Debug | grants the ability for debuggers to connect to a session
JRIExtensions | grants the use of MEMSTAT
Memory.Call | grants rights to call certain methods in `oracle.aurora.vm.OracleRuntime` on call settings
Memory.Stack | grants rights to call certain methods in `oracle.aurora.vm.OracleRuntime` on stack settings
Memory.SGAIntern | grants rights to call certain methods in `oracle.aurora.vm.OracleRuntime` on SGA settings
Memory.GC | grants rights to call certain methods in `oracle.aurora.vm.OracleRuntime` on garbage collector settings

#### Initial Permission Grants

When you first initialize JServer, several roles are populated with certain Permission grants. The following tables show these roles and their initial Permissions:

1. The JAVA_ADMIN role is given access to modify the policy table for all Permissions. All DBAs, including SYS, are granted JAVA_ADMIN. Full administrative rights to update the policy table are granted for the following Permissions:

   `java.util.PropertyPermission`
   `java.io.SerializablePermission`
   `java.io.FilePermission`
   `java.net.NetPermission`
   `java.net.SocketPermission`
   `java.lang.RuntimePermission`
   `java.lang.reflect.ReflectPermission`
   `java.security.SecurityPermission`
   `oracle.aurora.rdbms.security.PolicyTablePermission`
   `oracle.aurora.security.JServerPermission`

2. In addition to the JAVA_ADMIN Permissions, SYS is also granted the following Permissions:

   Note: Within the `RuntimePermission` grants, there seems to be unnecessary granting of more specific Permission for `loadlibrary`.<`package`>. The reason for this is to override the limitation given to PUBLIC for `loadLibrary.*`.

   ##### Table 5-3 SYS Initial Permissions

   Permission Type | Permission Name | Action Granted
   --- | --- | ---
   `oracle.aurora.rdbms.security. PolicyTablePermission` | `*` | Administrative rights to modify the policy table
   `oracle.aurora.security.JServerPermission` | `*` | null
   `java.net.NetPermission` | `*` | null
   `java.security.SecurityPermission` | `*` | null
   `java.util.PropertyPermission` | `*` | write
   `java.lang.reflect.ReflectPermission` | `*` | null
   `java.lang.RuntimePermission` | `*` | null
   | `loadLibrary.xaNative` | null
   | `loadLibrary.corejava` | null
   | `loadLibrary.corejava_d` | null

3. All users are initially granted the following Permissions. For the `JServerPermission`, all users can load classes, except for the list specified in the table. These exceptions are limitation Permissions. For more information on limitation Permissions, see Example 5-2.

   ##### Table 5-4 PUBLIC Default Permissions

   Permission Type | Permission Name | Granted Action
   --- | --- | ---
   `oracle.aurora.rdbms.security. PolicyTablePermission` | `java.lang.RuntimePermission. loadLibrary.*` | null
   `java.util.PropertyPermission` | `*` | read
   `` | `user.language` | write
   `java.lang.RuntimePermission` | `` | null
   `` | `exitVM` | null
   `` | `createSecurityManager` | null
   `` | `modifyThread` | null
   `` | `modifyThreadGroup` | null
   `oracle.aurora.security. JServerPermission` | `loadClassInPackage.* except for loadClassInPackage.java.*, loadClassInPackage.oracle.aurora.*,` and `loadClassInPackage.jdbc.*` | null

   ##### Table 5-5 JAVAUSERPRIV Permissions

   Permission Type | Permission Name | Action
   --- | --- | ---
   `java.net.SocketPermission` | `*` | connect, resolve
   `java.io.FilePermission` | `<<ALL FILES>>` | read
   `java.lang.RuntimePermission` | `modifyThreadGroup, stopThread, getProtectionDomain, readFileDescriptor, accessClassInPackage.*`, and `defineClassInPackage.*` | null

   ##### Table 5-6 JAVASYSPRIV Permissions

   Permission Type | Permission Name | Action
   --- | --- | ---
   `java.io.SerializablePermission` | * | no applicable action
   `java.io.FilePermission` | <<ALL FILES>> | read ,write, execute, delete
   `java.net.SocketPermission` | * | accept, connect, listen, resolve
   `java.lang.RuntimePermission` | `createClassLoader` | null
   | `getClassLoader` | null
   | `setContextClassLoader` | null
   | `setFactory` | null
   | `setIO` | null
   | `setFileDescriptor` | null
   | `readFileDescriptor` | null
   | `writeFileDescriptor` | null

   ##### Table 5-7 JAVADEBUGPRIV Permissions

   Permission Type | Permission Name | Action
   --- | --- | ---
   `oracle.aurora.security.JServerPermission` | `Debug` | null
   `java.net.SocketPermission` | * | connect, resolve

#### General Permission Definition Assigned to Roles

In 8.1.5, JVM security was controlled by granting the roles of JAVASYSPRIV, JAVAUSERPRIV, or JAVADEBUGPRIV to schemas. In the current version, these roles still exist as Permission groups. See the previous section, "Initial Permission Grants" for the explicit Permissions set for each role. You can set up and define your own collection of Permissions. Once defined, you can grant any collection of Permissions to any user. That user will then have the same Permissions that exist within the role. In addition, if you need additional Permissions, you can add individual Permissions to either your specified user or role. Permissions defined within the policy table have a cumulative effect. See "Fine-Grain Definition for Each Permission" for information on how to grant Permissions to a user or a role.

Note: The ability to write to properties, granted through the write action on `PropertyPermission`, is no longer granted to all users. Instead, you must either have JAVA_ADMIN grant you this Permission or you can receive this Permission by being granted the role of JAVASYSPRIV.

The following example gives Larry and Dave the following Permissions:

- Larry receives JAVASYSPRIV Permissions.

- Dave receives JAVADEBUGPRIV Permissions and the ability to read and write all files on the system.

      REM Granting Larry the same permissions as exist within JAVASYSPRIV
      grant javasyspriv to larry;

      REM Granting Dave the ability to debug
      grant javadebugpriv to dave;

      commit;

      REM I also want Dave to be able to read and write all files on the system
      call dbms_java.grant_permission('DAVE', 'SYS:java.io.FilePermission',
      	'<<ALL FILES>>', 'read,write', null);

### Debugging Permissions

A debug role, JAVADEBUGPRIV, was created to grant Permissions for running the debugger. The Permissions assigned to this role are listed in Table 5-7. In order to have permission to invoke the debug agent, the caller must have been granted JAVADEBUGPRIV or the debug `JServerPermission` as follows:

    REM Granting Dave the ability to debug
    grant javadebugpriv to dave;

    REM Larry grants himself permission to start the debug agent.
    call dbms_java.grant_permission
            ('LARRY', 'oracle.aurora.security.JServerPermission', 'Debug', null);

A debugger provides extensive access to both code and data on the server, but at this time, we envision its use to be limited to development environments. Refer to the discussion in the section "Debugging Server Applications" for information on using the debugging facilities in this release.

### Permission for Loading Classes

In order to load classes, you must have the following Permission:

    JServerPermission("LoadClassInPackage." + <class_name>)

The class name is the fully qualified name of the class that you are loading.

This excludes loading into system packages or replacing any system classes. Even if you are granted permission to load a system class, JServer prevents you from performing the load. System classes are classes that are installed by Oracle8i with CREATE JAVA SYSTEM. The following error is thrown if you try to replace a system class:

    ORA-01031 "Insufficient privileges"

The following shows the ability of each user after database installation, including Permissions and JServer restrictions:

- SYS can load any class, except for system classes.

- Any user can load classes in its own schema that do not start with the following patterns: `java.*`, `oracle.aurora.*`, `oracle.jdbc.*`. If the user wants to load such classes into another schema, it must be granted the `JServerPermission(LoadClassInPackage.<class>)` Permission.

The following example shows how to grant SCOTT Permission to load classes into the `oracle.aurora.*` package:

    dbms_java.grant_permission('SCOTT', 'SYS:oracle.aurora.tools.*', null);

| Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index