到现在为止，在本章中给出的基本算法中，AccessController自顶向下对栈进行检查，严格地要求每一个栈帧都有执行某个操作的权限，以防一段不可靠的代码隐藏在一段可信任代码后 面。因为AccessControIler-路向下地查看调用栈，所以，它最终会找到任何不能被允许执行被 请求操作的方法。例如，虽然Example2b中不被信任的Stranger对象将可信任的Friend和 TextFileDispIayer的代码放置它和在Java API方法的中间，其中，Java API的方法试图打开文件 answer.txt，但不被信任的Stranger代码仍然不能藏在被信任的代码后。就像图3-7所示，虽然 AccessController在到达栈帧2之前，必须检查八个栈帧是否拥有读取answer.txt文件的权限，它最终还是到达了栈帧2。一旦它到达了栈帧2,它将会发现和Stranger类的doYourThing ()方法 相关联的保护域没有读取answer.txt文件的权限。因此，这个AccessController将抛出一个 AccessControllerException,从而禁止了读取操作。
这个基本的AccessController算法防止了任何代码执行（或导致执行）任何不可信任的代码。 因此，属于一个权限较少的保护域的方法无权调用属于权限更高的保护域的方法。这个基本算法同时隐含了，如果一个属于较高权限保护域中的方法调用了属于较低权限保护域中的方法， 它必须自动放弃某些权限。虽然这个基本算法提供了一些一般情况下不需要的操作，但是 AccessComroHer严格坚持在调用栈中的所有栈帧都必须含有执行被请求操作的权限，而这一点 在很多情况下都太苛刻了。有的时候调用栈较上层（更靠近栈顶> 的代码可能希望执行一段 代码，而这段代码在调用栈的较下层是不允许执行的。例如，假设一个不可靠的applet请求Java API用bold Helvetica字体在它的applet面板中显示一个文本字符串。为了满足这个请求，java API可能需要打开一个本地硬盘上的字体文件，以装载applet显示文本所需要的bold Helvetica字体。一个类显式地请求打开这个字体文件，因为它属于Java API,所以它可能拥有打开这个文件
的权限。但是，这个不被信任的的代码是用调用栈下层的一个栈帧表示的，它很可能并不 拥有打开这个文件的权限。如果用这个基本的算法，AccessContrller将禁止打开这个宇体文件， 因为这个不被信任的applet的代码在栈中的没有打开这个文件的权限。
为了使可信的代码执行较不可靠的代码操作（这段不可靠的代码位于调用栈的较下层且没 有执行这个操作的权限），AccessController类重载了四个名为doPrivileged ()的静态方法。这 个四个方法的每一个都接受一个实现java.security.PrivilegedAction接口或者java.security. PrivilegedExcepdonAction接口的对象作为它的参数。这两个接口都声明了一个名为run ()的方 法，并且没有任何参数，返回void。这两个接口的惟一不同在于，PrivilegedExceptionAction的 run ()方法在它的throws子句中声明了Exception,而PrivilegedAction则没有声明throws子句。 要在调用栈较下层有不可信任代码的情况下执行某个操作，必须创建一个对象，它实现了一个 PrivilegedAction接口，它的run ()方法执行了这个操作，并且要将这个对象传递给 doPriviLeged()。
当调用doPrivileged {)方法时，就像调用其他任何方法一样，都会将一个新的栈帧压入栈。 在由AccessController执行的栈检查中，一个doPrivileged ()方法调用的栈帧标识了检查过程的 提前终止点。如果和调用doPrivileged ()的方法相关联的保护域拥有执行被请求操作的权限， AccessController将立即返回。这样这个操作就被允许，即使在栈下层的代码可能没有执行这个 操作的权限。
如果一个不可靠的applet请求Java API在它的applet面板上显示一个渕试字符串，Java API代 码通过把文件打开操作包装在一个doPrivileged ()调用中，就可以打开本地字体文件。 AccessController将允许这样的请求，即使这个不被信任的applet代码没有打开这个文件的权限。 因为这个不被信任的applet代码的栈帧位于由java API代码调用的doPrivileged ()栈帧的下方， AccessController甚至不必考虑不被信任的applet代码的权限。