The 1.1-Based Security Manager

In order to write a complete 1.1-based security manager, we must extend the SecurityManager class and use a number of its protected methods to determine certain information. In 1.1, the default implementation of each public method of the SecurityManager class is to throw an exception, so we must provide an implementation of all the methods we listed in Chapter 4. The security manager that we write will have a binary notion of trusted and untrusted classes.

Protected Methods of the Security Manager

The distinction that our security manager makes between trusted and untrusted code has its roots in information that the security manager must obtain from the class loader. We’ve seen part of one way that happens: the class loader can provide an agreed-upon interface that the security manager uses to obtain certain information. The second way that happens is by using the protected methods of the security manager; they are summarized in Table D-1. Use of these methods is discouraged in Java 2; most of them are officially deprecated, and the remainder should be avoided.

Table D-1. Protected Methods of the Security Manager Class

Method

Purpose

getClassContext(  )

Return all the classes on the stack to see who has called us

currentClassLoader(  )

Return the most recent class loader

currentLoadedClass(  )

Return the class that was most recently loaded with a class loader

classLoaderDepth(  )

Return the depth in the call stack where the most recent ...

Get Java Security, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.