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 ... |
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access