Permission


Permission java.security

Java 1.2 serializable 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( )



Java In A Nutshell
Java In A Nutshell, 5th Edition
ISBN: 0596007736
EAN: 2147483647
Year: 2004
Pages: 1220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net