|Oracle8i Enterprise JavaBeans and CORBA Developer's Guide
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:
Use the SQL command REVOKE EXECUTE to remove execute rights for a user from a loaded Java class.
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:
-grantoption with the
chowncommands within the Session Shell
Note that you have to be connected to the Session Shell as the user SYS to 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.
There are three "built-in" server objects that a client can access without being authenticated. They are:
These objects can be activated using
servicectx.lookup() without authentication. See "explicit" for an example that access the
Login object explicitly.
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.