程序员写一个Java程序，默认的情况下你可以访问任意的机器资源，比如读取，删除一些文件或者网络操作等。当你把程序部署到正式的服务器上，系统管理员要为服务器的安全承担责任，那么他可能不敢确定你的程序会不会访问不该访问的资源，为了消除潜在的安全隐患，他可能有两种办法：1，让你的程序在一个限定权限的帐号下运行；
2.利用Java的沙箱机制来限定你的程序不能为非作歹。我们这里主要谈谈后一种方法。
怎样给一个程序设置一个“沙箱”呢？这个设置应该是避免改动程序代码的，而且是简单易行的。根据Java的文档，我们了解到只需简单的两个步骤。
步骤一.加一个运行参数，就可以让一个程序在沙箱里运行：
java -Djava.security.manager -jar myapp.jar
步骤二.设置具体的权限，比如创建自己的策略文件myapp.policy：
grant codeBase "file:${user.dir}/myapp.jar" {
permission java.io.FilePermission "${user.dir}${/}*", "read";
};
这个设置的意思是，从myapp.jar载入的代码，对当前目录下的所有文件有“读”的权限。
做完这两个步骤后，运行命令：
java -Djava.security.manager -Djava.security.policy==myapp.policy -jar myapp.jar
就可以保证程序只拥有你指明的权限。当访问其他资源时，会抛出类似"access denied"的异常。系统默认的策略文件是${java.home}/jre/lib/security/java.policy,它拥有的权限非常少，而且都与访问系统资源无关。
那么问题随之而来，这一切是怎么实现的？检查的代码在哪里，又是谁来开发的这些代码？
答案是：这是SUN干的，SUN早把这些检查的代码插入到所有访问系统资源的API里面了。
举一个读取文件的例子，比如：
BufferedReader br = new BufferedReader(new FileReader(fileName));
String line = br.readLine()；
当你运行到第一行，继续调试进Java API源代码里，就可以碰到下面的一段代码：
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkRead(name);
}
这里的代码表示，如果安装了SecurityManager，那么将进行安全检查（是否对这个文件具有读的权限）。而当你加上运行参数-Djava.security.manager，即表示安装了SecurityManager。这里和上面的第一个步骤对应。
继续调试进去，看到下面的代码：
checkPermission(new FilePermission(file,
SecurityConstants.FILE_READ_ACTION));
很明显，这和上面的第二个步骤对应，FilePermission即为java.io.FilePermission，FILE_READ_ACTION即为“read”。
那么codeBase和什么对应呢？
codeBase涉及到ClassLoader方面的知识了，简单的说，ClassLoader加载一些代码的时候，它会把代码来源的信息保存下来，这些信息结合从策略文件里读取的信息，系统就可以来做出决策了。
细节总是复杂的，但在理解这个原理后去深入细节，就能起到引领的作用。 这里最让人疑惑的地方不是策略文件的配置和规则，而是谁在决策，在什么时候决策。可能有人提出一个问题，如果我不用SUN的API，我自己去写一些代码访问机器上的资源，那不就可以绕开“沙箱”了吗？理论上是可以的，但只要你写的是Java代码，并且仍使用SUN的虚拟机，那么你就没有这个机会。SUN的类加载器机制保证了你不能去替代或者干涉它的核心类库。
2.利用Java的沙箱机制来限定你的程序不能为非作歹。我们这里主要谈谈后一种方法。
怎样给一个程序设置一个“沙箱”呢？这个设置应该是避免改动程序代码的，而且是简单易行的。根据Java的文档，我们了解到只需简单的两个步骤。
步骤一.加一个运行参数，就可以让一个程序在沙箱里运行：
java -Djava.security.manager -jar myapp.jar
步骤二.设置具体的权限，比如创建自己的策略文件myapp.policy：
grant codeBase "file:${user.dir}/myapp.jar" {
permission java.io.FilePermission "${user.dir}${/}*", "read";
};
这个设置的意思是，从myapp.jar载入的代码，对当前目录下的所有文件有“读”的权限。
做完这两个步骤后，运行命令：
java -Djava.security.manager -Djava.security.policy==myapp.policy -jar myapp.jar
就可以保证程序只拥有你指明的权限。当访问其他资源时，会抛出类似"access denied"的异常。系统默认的策略文件是${java.home}/jre/lib/security/java.policy,它拥有的权限非常少，而且都与访问系统资源无关。
那么问题随之而来，这一切是怎么实现的？检查的代码在哪里，又是谁来开发的这些代码？
答案是：这是SUN干的，SUN早把这些检查的代码插入到所有访问系统资源的API里面了。
举一个读取文件的例子，比如：
BufferedReader br = new BufferedReader(new FileReader(fileName));
String line = br.readLine()；
当你运行到第一行，继续调试进Java API源代码里，就可以碰到下面的一段代码：
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkRead(name);
}
这里的代码表示，如果安装了SecurityManager，那么将进行安全检查（是否对这个文件具有读的权限）。而当你加上运行参数-Djava.security.manager，即表示安装了SecurityManager。这里和上面的第一个步骤对应。
继续调试进去，看到下面的代码：
checkPermission(new FilePermission(file,
SecurityConstants.FILE_READ_ACTION));
很明显，这和上面的第二个步骤对应，FilePermission即为java.io.FilePermission，FILE_READ_ACTION即为“read”。
那么codeBase和什么对应呢？
codeBase涉及到ClassLoader方面的知识了，简单的说，ClassLoader加载一些代码的时候，它会把代码来源的信息保存下来，这些信息结合从策略文件里读取的信息，系统就可以来做出决策了。
细节总是复杂的，但在理解这个原理后去深入细节，就能起到引领的作用。 这里最让人疑惑的地方不是策略文件的配置和规则，而是谁在决策，在什么时候决策。可能有人提出一个问题，如果我不用SUN的API，我自己去写一些代码访问机器上的资源，那不就可以绕开“沙箱”了吗？理论上是可以的，但只要你写的是Java代码，并且仍使用SUN的虚拟机，那么你就没有这个机会。SUN的类加载器机制保证了你不能去替代或者干涉它的核心类库。