THE Java™ Programming Language, Fourth Edition

(Jeff_L) #1

The security manager is given an opportunity to prevent completion of the operation by throwing an
exception. A security manager routine simply returns if the operation is permitted but throws a
SecurityException if the operation is not permitted.


You can get and set the security manager with methods of the System class:


public static voidsetSecurityManager(SecurityManager s)

Sets the system security manager object. If a security manager already exists
this new manager will replace it, provided the existing manager supports
replacement and you have permission to replace it; otherwise, a
SecurityException is thrown.

public static SecurityManagergetSecurityManager()

Gets the system security manager. If none has been set null is returned and
you are assumed to have all permissions.

The security manager delegates the actual security check to an access control object. Each check method just
invokes the security manager's checkPermission method, passing the appropriate
java.security.Permission object for the requested action. The default implementation of
checkPermission then calls


java.security.AccessController.checkPermission(perm);


If a requested access is allowed, checkPermission returns quietly. If denied, a
java.security.AccessControlException (a type of SecurityException) is thrown.


This form of checkPermission always performs security checks within the context of the current
threadwhich is basically the set of protection domains of which it is a member. Given that a protection domain
is a set of classes with the same permissions, a thread can be a member of multiple protection domains when
the call stack contains active methods on objects of different classes.


The security manager's getSecurityContext method returns the security context for a thread as a
java.security.AccessControlContext object. This class also defines a checkPermission
method, but it evaluates that method in the context that it encapsulates, not in the context of the calling thread.
This feature is used when one context (such as a thread) must perform a security check for another context.
For example, consider a worker thread that executes work requests from different sources. The worker thread
has permission to perform a range of actions, but the submitters of work requests may not have those same
permissions. When a work request is submitted, the security context for the submitter is stored along with the
work request. When the worker thread performs the work, it uses the stored context to ensure that any security
checks are performed with respect to the submitter of the request, not the worker thread itself. In simple cases,
this might involve invoking the security manager's two-argument checkPermission method, which takes
both a Permission object and an AccessControlContext object as arguments. In more general
situations, the worker thread may use the doPrivileged methods of AccessController, which you
will learn about shortly.


23.5.2. Permissions


Permissions fall into a number of categories, each managed by a particular class, for example:



  • File java.io.FilePermission

Free download pdf