Access Rights to Database Objects

In addition to authentication and privacy, Oracle8i also supports controlled access to the classes that make up CORBA and EJB objects. Only users or roles that have been granted EXECUTE rights to the Java class of an object stored in the database can activate the object and invoke methods on it.

You can control execute rights on Java classes at class load time with the -grant argument to loadjava. See "loadjava" for more information about loadjava. See the Oracle8i Java Developer's Guide for more information about access rights on Java classes in the database.

You use the SQL DDL GRANT EXECUTE command to grant execute permission on a Java class loaded in the database. For example, if SCOTT has loaded a class Hello, then SCOTT (or SYS) can grant execute privileges on that class to another user, say OTTO, by issuing the SQL command:

SQL> GRANT EXECUTE ON "Hello" TO OTTO;

Use the SQL command REVOKE EXECUTE to remove execute rights for a user from a loaded Java class.

Published Objects

Published objects are not restricted to a specific schema; they are potentially available to all users in the instance. You can control permissions on a published object in two ways:

• using the -grant option with the publish tool

• using the chmod and chown commands within the Session Shell

Note that you have to be connected to the Session Shell as the user SYS to use the chown command.

Use the ls -l command in the session shell to view the permissions (EXECUTE, READ, and WRITE) and the owner of a published object.

See the descriptions of these tools in Chapter 6 for more information.

Published objects have permissions that can differ from those of the underlying classes. For example, if user SCOTT has execute permission on a published object name, but does not have execute permission on the class that the published object "represents", then SCOTT will not be able to activate the object.

Other Server Objects

There are three "built-in" server objects that a client can access without being authenticated. They are:

• the Name Service

• the InitialReferences object (the boot service)

• the Login object

These objects can be activated using servicectx.lookup() without authentication. See "explicit" for an example that access the Login object explicitly.

Reauthentication

When a client receives an IOR from another client, the first time it tries to send a message to the object it must be authenticated by the server, and the server must verify that the authenticated client has access rights to the object.

---