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.