关于SecurityManager

 

首先申明下，这个题目是在别的网友的博客上看到的，本人最近正在学习SecurityManager所以在他基础上作出一些讨论

--------------------------------------------------------------------------------------------------------------------

关于Java SecurityManager

最近看到一道题问：

Which five statements about SecurityManager are true?(Choose five.)
A. The SecurityManager must be instantiated to use RMI.
B. The SecurityManager can be discarded after loading.
C. The SecurityManager can be configured from a per-user file.
D. The SecurityManager can be configured from a system-wide file.
E. The SecurityManager can be installed in the application code.
F. The SecurityManager can be installed from the command line.
G. The SecurityManager can be configured from a file specified on the common line.  

这是一个安全方面的问题。题中提到的SecurityManager实际上指的是java.lang.SecurityManager。

SecurityManager是一个Java类（Java 1.2以前是一个抽象类），在1.2以后的版本中已经是个实例类。

应用程序可以通过它实现一个安全策略(Permission)。它允许应用程序在调用可能的不安全的或是敏感的操作前检查这个操作到底是什么；以及它在当前的上下文中是否被允许运行。

我们可以通过如下方法获得当前的SecurityManager：

SecurityManager security = System.getSecurityManager();

同样，我们也可以付给当前一个新的SecurityManager：

SecurityManager sm = new SecurityManager();

System.setSecurityManager(sm);

但前提是上一个SecurityManager允许我们创建一个新的来取代他，这个定义在java.policy文件中：

permission java.lang.RuntimePermission "createSecurityManager";

默认的java.policy文件中似乎没有该项。

好了，说了这么多废话，现在我们切入正题：到底哪5个答案是对的呢？我们来一个一个分析。<<其实这个题的答案是我从题库中找来的，回过头来看看我的分析，感觉有些不对劲，似乎是题库的答案错了。下面的黑体字是我认为正确的答案！>>

A. The SecurityManager must be instantiated to use RMI.

是指在远程的方法调用时候必须先实例化一个SecurityManager 。而SecurityManager的确有一个关于RMI的子类，叫RMISecurityManager。Java  API中关于RMISecurityManager的说法如下：

 由使用下载的代码的 RMI 应用程序使用的 SecurityManager 的子类。如果尚未设置安全管理器，则 RMI 的类加载器不会从远程位置下载任何子类。RMISecurityManager 不用于 applet，它们的运行受其浏览器的安全管理器保护。RMISecurityManager 实现一个与 SecurityManager 实现的策略相同的策略。因此，RMI 应用程序应该使用 SecurityManager 类或其他代替此类的特定于应用程序的 SecurityManager 实现。

<<既然没有SecurityManager，RMI就不能正常下载远程代码，那我觉得这个选项就是对的——SecurityManager必须被实例化以用来使用RMI>>  A正确

B. The SecurityManager can be discarded after loading.

关于这个选项我是这样理解的：SecurityManager一旦被加载了就不能被抛弃，只能被一个新的所覆盖。在《深入jvm》一书中明确的提到：在java的1.0和1.1版本中，如果应用程序安装的了安全管理器，那么它将在应用程序的剩下的生命周期中都起到作用，不能被覆盖或者修改。而在1.2版本，它允许被其他管理器所替换。主要通过System.setSecurityManager()来实现。

C. The SecurityManager can be configured from a per-user file.

哈哈，关于这个选项的实例我还没有找到，等找到了再写在这里，我相信SecurityManager有这么“强大”的功能：P <<既然找不到例子，就等于说这个选项是不对的！>>

D. The SecurityManager can be configured from a system-wide file.

也就是说SecurityManager可以用一个系统中的文件进行配置，而不只是${Java_Home}/jre/lib/security/java.policy文件。一个例子是我们可以使用-Djava.security.policy=或是-Djava.security.policy==来指定策略文件的位置，其中=表示这个策略文件将和默认的策略文件一同发挥作用；==表示只使用这个策略文件。

E. The SecurityManager can be installed in the application code.

下面就是一段这样的代码：

SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
if (sm != null) {
Permission p = new FilePermission("/temp/*", "write");
System.out.println(p.getActions());
sm.checkPermission(p);
}

在某些J2EE Server的配置文件中也可以配置安全策略，如：

      <weblogic-enterprise-bean>
　　<!-- webLogic enterprise bean statements go here -->
　　</weblogic-enterprise-bean>
　　<security-role-assignment>
　　<!-- the optional security role assignments go here -->
　　</security-role-assignment>
　　<security-permission>
　　<description>
　　grant permission to special folder
　　</description>
　　<security-permission-spec>
　　grant {
　　permission java.io.FilePermission "D:/temp", "read";
        };
      <security-permission-spec>
      <security-permission>

F. The SecurityManager can be installed from the command line.

命令如下：

-Djava.security.manager=org.faquir.MySecurityManager

G. The SecurityManager can be configured from a file specified on the common line.

这个例子也就是D中提到的那个。

OK，这个题的答案就是C、D、E、F、G。 <<所以，改正后的答案是A、D、E、F、G>>