Java Unsigned Applet - 忽略传递 VM 参数“java.security.policy”？答案

【问题标题】：Java Unsigned Applet - Passing VM-argument "java.security.policy" is ignored?Java Unsigned Applet - 忽略传递 VM 参数“java.security.policy”？
【发布时间】：2013-09-11 05:23:01
【问题描述】：

在有人问我为什么我这样做之前，或者建议我签署小程序，或者在 J2EE 客户端权限下通过 JWS 部署它之前，这纯粹是出于学术原因并满足我自己的好奇心.

我正在尝试提供一个 VM 参数 (java.security.policy) 来指向用于管理相关小程序的策略文件，如下所示，但它似乎被忽略了，始终引发安全异常。我在 Oracle 的文档中找不到任何说明这是可以预期的。任何人都可以为我阐明这一点吗？谢谢

（结果）

java.security.AccessControlException: access denied ("java.io.FilePermission" "frustrated.txt" "write")

(html)

<html>
    <body>
        <applet name ="Frustrated" 
                code="com.test.Main.class" 
                archive="Frustrated.jar" 
                width="100" 
                height="100"
        >
            <PARAM name="separate_jvm" value="true">
            <PARAM name="java_arguments" value="-Djava.security.policy=C:\Frustrated.policy">
        </applet>
    </body>
</html>

(java)

package com.test;

import java.applet.Applet;
import java.io.FileOutputStream;
import java.io.IOException;

@SuppressWarnings("serial")
public class Main extends Applet
{
    @Override
    public final void init()
    {
        try
        {
            new FileOutputStream("frustrated.txt");
        }
        catch (IOException e) { }
    }
}

（政策）

grant
{
    permission java.security.AllPermission;
};

【问题讨论】：

标签： java security applet unsigned policy

【解决方案1】：

<PARAM name="java_arguments" value="-Djava.security.policy=C:\Frustrated.policy">

如果可以通过小程序参数建立自定义策略，那将是一个（严重的）安全漏洞。

顺便说一句。鉴于这是出于“纯粹的学术原因”，我将添加我的常见建议之一。小程序和学术界。

为什么要编写小程序？如果是由于规范。老师请转至Why CS teachers should stop teaching Java applets。

【讨论】：

虽然这是我的想法和预期，但 Oracle 关于此事的文档并不存在（或者至少我似乎找不到它）。希望其他搜索过答案的人在像我今晚一样浪费 4 小时重新阅读文档之前偶然发现了这个页面。顺便说一句，我认为大多数 CS 老师应该停止教学 - 期间。相反，将工作分配给那些在该学科领域拥有当前现实世界经验的人，而不是书本精明的理论教授。
“把工作交给那些在这个领域有当前实际经验的人，而不是书本精明的理论教授。”并能够将这种专业知识传授给他人。就个人而言，我更喜欢一位出色的老师，但在该领域的经验有限，而不是无法教书以挽救生命的专家。此外，那些拥有“现实世界经验”的人通常比教育机构准备或能够支付的收入要多得多。 ;)
...好像我无法编辑我以前的评论，所以我将只做一个新的。您能否将我链接到您找到此信息的权威来源？
不，我不能。它可能是从其他资源和过去经验的（模糊）集合中推断出来的。对于普通的小程序/JWS 应用程序，JVM 会经历一个“检查安全证书并提示用户”的过程。虽然 JRE 可能被配置为在看到该参数时提示用户，但代码可能是未签名的。随着 Oracle 的发展，在默认安全设置下，JRE 甚至会拒绝“自签名”代码。未签名的代码？算了。。为了让 Java 被视为安全，这是行不通的。
对此事的最后评论...我觉得很奇怪，策略文件要么看似被接受，要么在使用与 JDK 捆绑在一起的 appletviewer 工具时被简单地取消沙箱化。这就是最初让我相信我最初的期望并非如此的原因。