This abstract class represents a system
resource, such as a file in the filesystem, or a system capability,
such as the ability to accept network connections. Concrete
subclasses of Permission, such as
java.io.FilePermission and
java.net.SocketPermission, represent specific
types of resources. Permission objects are used by
system code that is requesting access to a resource. They are also
used by Policy objects that grant access to
resources. The AccessController.checkPermission( )
method considers the source of the currently running Java code,
determines the set of permissions that are granted to that code by
the current Policy, and then checks to see whether
a specified Permission object is included in that
set. As of Java 1.2, this is the fundamental Java access-control
mechanism.
Each permission has a name (sometimes called the
target) and, optionally, a comma-separated list
of actions. For example, the name of a
FilePermission is the name of the file or
directory for which permission is being granted. The actions
associated with this permission might be
"read";
"write"; or
"read,write". The interpretation of
the name and action strings is entirely up to the implementation of
Permission. A number of implementations support
the use of wildcards; for example, a
FilePermission can have a name of
"/tmp/*", which represents access
to any files in a /tmp directory. Permission
objects must be immutable, so an implementation must never define a
setName( ) or setActions( )
method.
One of the most important abstract
methods defined by Permission is implies(
). This method must return true if this
Permission implies another
Permission. For example, if an application
requests a FilePermission with name
"/tmp/test" and action
"read", and the current security
Policy grants a FilePermission
with name "/tmp/*" and actions
"read,write", the request is
granted because the requested permission is implied by the granted
one.
In general, only system-level code needs to work directly with
Permission and its concrete subclasses. System
administrators who are configuring security policies need to
understand the various Permission subclasses.
Applications that want to extend the Java access-control mechanism to
provide customized access control to their own resources should
subclass Permission to define custom permission
types.
public abstract class Permission implements Guard, Serializable {
// Public Constructors
public Permission(String name);
// Public Instance Methods
public abstract String getActions( );
public final String getName( );
public abstract boolean implies(Permission permission);
public PermissionCollection newPermissionCollection( ); constant
// Methods Implementing Guard
public void checkGuard(Object object) throws SecurityException;
// Public Methods Overriding Object
public abstract boolean equals(Object obj);
public abstract int hashCode( );
public String toString( );
}
Too many methods to list.
