permission java.io.FilePermission "/tmp/abc", "read";
};
To find out how security policies are defined in your local system, consult your local documentation.
Classes loaded by the bootstrap loader are considered to be trusted and do not need explicit permissions set in
the security policy. Some virtual machine implementations also support the standard extensions mechanism,
which allows classes to be identified as trusted by placing them in special locations accessed by the extensions
class loader. These classes do not need explicit permissions set either.
23.5.4. Access Controllers and Privileged Execution
The AccessController class is used for three purposes:
It provides the basic checkPermission method used by security managers to perform a security
check.•
It provides a way to create a "snapshot" of the current calling context by using getContext, which
returns an AccessControlContext.•
It provides a means to run code as privileged, thus changing the set of permissions that might
otherwise be associated with the code.•
We have discussed (to the extent we intend to) the first two of these. In this section we look at what it means
to have privileged execution.
A protection domain (represented by java.security.ProtectionDomain) encompasses a code
source (represented by java.security.CodeSource) and the permissions granted to code from that
code source, as determined by the security policy currently in effect. A code source extends the notion of a
code base (the location classes were loaded from) to include information about the digital certificates
associated with those classes. Digital certificates can be used to verify the authenticity of a file and ensure that
the file has not been tampered with in any way. Classes with the same certificates and from the same location
are placed in the same domain, and a class belongs to one and only one protection domain. Classes that have
the same permissions but are from different code sources belong to different domains.
Each applet or application runs in its appropriate domain, determined by its code source. For an applet (or an
application running under a security manager) to be allowed to perform a secured action, the applet or
application must be granted permission for that particular action. More specifically, whenever a secure action
is attempted, all code traversed by the execution thread up to that point must have permission for that action
unless some code on the thread has been marked as privileged. For example, suppose that access control
checking occurs in a thread of execution that has a chain of multiple callersthink of this as multiple method
calls that potentially cross the protection domain boundaries. When the
AccessControllercheckPermission method is invoked by the most recent caller, the basic
algorithm for deciding whether to allow or deny the requested action is as follows:
If the code for any caller in the call chain does not have the requested permission, an
AccessControlException is thrown, unless a caller whose code is granted the said
permission has been marked as privileged and all parties subsequently called by this caller
(directly or indirectly) have the said permission.Marking code as privileged enables a piece of trusted code to temporarily enable access to more actions than
are directly available to the code that called it. This is necessary in some situations. For example, an
application may not be allowed direct access to files that contain fonts, but the system utility to display a
document must obtain those fonts on behalf of the user. This requires that the system utility code becomes