Java in a Nutshell, 5th Edition [Electronic resources] نسخه متنی

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.

Figure 14-27. java.security.Permission

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 ( );
}

Subclasses

java.io.FilePermission,
java.net.SocketPermission,
AllPermission, BasicPermission,
UnresolvedPermission,
javax.security.auth.PrivateCredentialPermission,
javax.security.auth.kerberos.ServicePermission

Passed To

Too many methods to list.

Returned By

java.net.HttpURLConnection.getPermission( ),
java.net.URLConnection.getPermission( ),
AccessControlException.getPermission( )