The SecurityManager class contains many methods with names that begin with the word check. These methods are called by various methods in the Java libraries before those methods perform certain potentially sensitive operations. The invocation of such a check method typically looks like this:
SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkXXX(argument, . . . ); } The security manager is thereby 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. The only exception to this convention is checkTopLevelWindow, which returns a boolean value.
The current security manager is set by the setSecurityManager method in class System. The current security manager is obtained by the getSecurityManager method.
The special method {@link SecurityManager#checkPermission(java.security.Permission)}determines whether an access request indicated by a specified permission should be granted or denied. The default implementation calls
AccessController.checkPermission(perm);
If a requested access is allowed, checkPermission returns quietly. If denied, a SecurityException is thrown.
As of Java 2 SDK v1.2, the default implementation of each of the other check methods in SecurityManager is to call the SecurityManager checkPermission method to determine if the calling thread has permission to perform the requested operation.
Note that the checkPermission method with just a single permission argument always performs security checks within the context of the currently executing thread. Sometimes a security check that should be made within a given context will actually need to be done from within a different context (for example, from within a worker thread). The {@link SecurityManager#getSecurityContext getSecurityContext} method and the {@link SecurityManager#checkPermission(java.security.Permission,java.lang.Object) checkPermission}method that includes a context argument are provided for this situation. The getSecurityContext method returns a "snapshot" of the current calling context. (The default implementation returns an AccessControlContext object.) A sample call is the following:
Object context = null; SecurityManager sm = System.getSecurityManager(); if (sm != null) context = sm.getSecurityContext();
The checkPermission method that takes a context object in addition to a permission makes access decisions based on that context, rather than on that of the current execution thread. Code within a different context can thus call that method, passing the permission and the previously-saved context object. A sample call, using the SecurityManager sm obtained as in the previous example, is the following:
if (sm != null) sm.checkPermission(permission, context);
Permissions fall into these categories: File, Socket, Net, Security, Runtime, Property, AWT, Reflect, and Serializable. The classes managing these various permission categories are java.io.FilePermission, java.net.SocketPermission, java.net.NetPermission, java.security.SecurityPermission, java.lang.RuntimePermission, java.util.PropertyPermission, java.awt.AWTPermission, java.lang.reflect.ReflectPermission, and java.io.SerializablePermission.
All but the first two (FilePermission and SocketPermission) are subclasses of java.security.BasicPermission, which itself is an abstract subclass of the top-level class for permissions, which is java.security.Permission. BasicPermission defines the functionality needed for all permissions that contain a name that follows the hierarchical property naming convention (for example, "exitVM", "setFactory", "queuePrintJob", etc). An asterisk may appear at the end of the name, following a ".", or by itself, to signify a wildcard match. For example: "a.*" or "*" is valid, "*a" or "a*b" is not valid.
FilePermission and SocketPermission are subclasses of the top-level class for permissions (java.security.Permission). Classes like these that have a more complicated name syntax than that used by BasicPermission subclass directly from Permission rather than from BasicPermission. For example, for a java.io.FilePermission object, the permission name is the path name of a file (or directory).
Some of the permission classes have an "actions" list that tells the actions that are permitted for the object. For example, for a java.io.FilePermission object, the actions list (such as "read, write") specifies which actions are granted for the specified file (or for files in the specified directory).
Other permission classes are for "named" permissions - ones that contain a name but no actions list; you either have the named permission or you don't.
Note: There is also a java.security.AllPermission permission that implies all permissions. It exists to simplify the work of system administrators who might need to perform multiple tasks that require all (or numerous) permissions.
See Permissions in the JDK for permission-related information. This document includes, for example, a table listing the various SecurityManager check methods and the permission(s) the default implementation of each such method requires. It also contains a table of all the version 1.2 methods that require permissions, and for each such method tells which permission it requires.
For more information about SecurityManager changes made in the JDK and advice regarding porting of 1.1-style security managers, see the security documentation.
@author Arthur van Hoff
@author Roland Schemers
@version 1.139, 04/21/06
@see java.lang.ClassLoader
@see java.lang.SecurityException
@see java.lang.SecurityManager#checkTopLevelWindow(java.lang.Object) checkTopLevelWindow
@see java.lang.System#getSecurityManager() getSecurityManager
@see java.lang.System#setSecurityManager(java.lang.SecurityManager) setSecurityManager
@see java.security.AccessController AccessController
@see java.security.AccessControlContext AccessControlContext
@see java.security.AccessControlException AccessControlException
@see java.security.Permission
@see java.security.BasicPermission
@see java.io.FilePermission
@see java.net.SocketPermission
@see java.util.PropertyPermission
@see java.lang.RuntimePermission
@see java.awt.AWTPermission
@see java.security.Policy Policy
@see java.security.SecurityPermission SecurityPermission
@see java.security.ProtectionDomain
@since JDK1.0
SecurityManager is responsible for managing one or more security providers.
| |
| |