Java in a Nutshell, 5th Edition [Electronic resources]

نسخه متنی -صفحه : 1191/ 534
نمايش فراداده

Permissionjava.security

Java 1.2serializable permission

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