在Java 9+中启动jstatd [英] Starting jstatd in Java 9+

问题描述

过去，我已经通过安全策略文件启动了jstatd，如下所示: https://stackoverflow.com/a/14930180/1294116

In the past, I have started jstatd via a security policy file, as suggested here: https://stackoverflow.com/a/14930180/1294116

但是，在Java 9+中，他们删除了tools.jar文件，这意味着该解决方案不再起作用.有谁知道如何解决这个问题? (目前，我又回到了错误java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.rmi.server.ignoreSubClasses" "write") ...)

However, in Java 9+, they have removed the tools.jar file, which means that this solution no longer works. Does anyone know how to get around this? (Currently I am back to getting the error java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.rmi.server.ignoreSubClasses" "write") ...)

推荐答案

解决方案

以下策略文件应该对您有用(至少在Java 11下):

Solution

The following policy file should work for you (at least under Java 11):

grant codebase "jrt:/jdk.jstatd" {    
   permission java.security.AllPermission;    
};

grant codebase "jrt:/jdk.internal.jvmstat" {    
   permission java.security.AllPermission;    
};

感谢塞巴斯蒂安S 指出jdk.internal.jvmstat，还需要获得相应的许可并进行确认以上作品.还要感谢 Gili .

Thanks to Sebastian S for pointing out jdk.internal.jvmstat also needed to be granted the appropriate permission and for confirming the above works. Thanks to Gili for the latter as well.

如下所示，tools.jar文件已被删除，其中的所有内容均被拆分为多个模块. jstatd工具现在位于

As shown below, the tools.jar file was removed and everything in it was split up into modules. The jstatd tool now resides in the jdk.jstatd module. I couldn't find documentation regarding how it was determined which tool(s) went into which module, though the Javadoc does tell you after-the-fact. Just note that some modules contain the code for a single tool while other modules contain the code for multiple tools.

来自政策文件语法文档:

如果使用的是模块化运行时映像(请参见jlink工具)，则可以通过在策略文件中将jrt URL指定为codeBase值来授予对映像中的应用程序和库模块的权限. .有关jrt URL的更多信息，请参见 JEP 220:模块化运行时图像.

If you are using a modular runtime image (see the jlink tool), you can grant permissions to the application and library modules in the image by specifying a jrt URL as the codeBase value in a policy file. See JEP 220: Modular Run-Time Images for more information about jrt URLs.

下面的示例向模块com.greetings授予读取foo属性的权限:

The following example grants permission to read the foo property to the module com.greetings:

grant codeBase "jrt:/com.greetings" {
   permission java.util.PropertyPermission "foo", "read";
};

来自 JEP 200:模块化JDK :

设计原则

JDK的模块化结构实现了以下原则:

The modular structure of the JDK implements the following principles:

• 由JCP规范其规范的标准模块的名称以字符串"java."开头.
• 所有其他模块仅是JDK的一部分，并且名称以字符串"jdk."开头.

• Standard modules, whose specifications are governed by the JCP, have names starting with the string "java.".
• All other modules are merely part of the JDK, and have names starting with the string "jdk.".

[...]

来自 JEP 220:模块化运行时图像:

摘要

重组JDK和JRE运行时映像以容纳模块并提高性能，安全性和可维护性.定义新的URI方案，以命名存储在运行时映像中的模块，类和资源，而无需透露映像的内部结构或格式.根据需要修改现有规范以适应这些更改.

Summary

Restructure the JDK and JRE run-time images to accommodate modules and to improve performance, security, and maintainability. Define a new URI scheme for naming the modules, classes, and resources stored in a run-time image without revealing the internal structure or format of the image. Revise existing specifications as required to accommodate these changes.

[...]

已删除:rt.jar和tools.jar

Removed: rt.jar and tools.jar

以前存储在lib/rt.jar，lib/tools.jar，lib/dt.jar中的类和资源文件以及其他各种内部JAR文件现在以更有效的格式存储在lib目录中的特定于实现的文件中.这些文件的格式未指定，如有更改，恕不另行通知.

The class and resource files previously stored in lib/rt.jar, lib/tools.jar, lib/dt.jar, and various other internal JAR files are now stored in a more efficient format in implementation-specific files in the lib directory. The format of these files is not specified and is subject to change without notice.

删除rt.jar和类似文件会导致三个不同的问题:

The removal of rt.jar and similar files leads to three distinct problems:

1. [...]

java.security.CodeSource API和安全策略文件使用URL命名要授予指定权限的代码库的位置.当前在lib/security/java.policy文件中通过文件URL标识了需要特定权限的运行时系统组件.椭圆曲线密码提供程序例如被标识为

The java.security.CodeSource API and security-policy files use URLs to name the locations of code bases that are to be granted specified permissions. Components of the run-time system that require specific permissions are currently identified in the lib/security/java.policy file via file URLs. The elliptic-curve cryptography provider, e.g., is identified as

file:${java.home}/lib/ext/sunec.jar

显然，在模块化图像中没有任何意义.

which, obviously, has no meaning in a modular image.

[...]

用于命名存储的模块，类和资源的新URI方案

New URI scheme for naming stored modules, classes, and resources

要解决上述三个问题，可以使用新的URL方案jrt命名运行时映像中存储的模块，类和资源，而无需透露映像的内部结构或格式.

To address the above three problems a new URL scheme, jrt, can be used to name the modules, classes, and resources stored in a run-time image without revealing the internal structure or format of the image.

jrt URL是根据RFC 3986使用语法的分层URI

A jrt URL is a hierarchical URI, per RFC 3986, with the syntax

jrt:/[$MODULE[/$PATH]]

其中，$MODULE是可选的模块名称，而$PATH(如果存在)是该模块中特定类或资源文件的路径. jrt URL的含义取决于其结构:

where $MODULE is an optional module name and $PATH, if present, is the path to a specific class or resource file within that module. The meaning of a jrt URL depends upon its structure:

• [...]

jrt:/$MODULE引用模块$MODULE中的所有类和资源文件.

jrt:/$MODULE refers to all of the class and resource files in the module $MODULE.

[...]

这三种jrt URL形式解决了以下问题:

These three forms of jrt URLs address the above problems as follows:

1. [...]

安全策略文件和CodeSource API的其他用途可以使用jrt URL来命名特定的模块，以授予权限.椭圆曲线密码提供程序，例如，现在可以通过jrt URL

Security-policy files and other uses of the CodeSource API can use jrt URLs to name specific modules for the purpose of granting permissions. The elliptic-curve cryptography provider, e.g., can now be identified by the jrt URL

jrt:/jdk.crypto.ec

当前被授予了所有权限但实际上并不需要它们的其他模块，可以简单地取消特权，即，精确地赋予它们所需的权限.

Other modules that are currently granted all permissions but do not actually require them can trivially be de-privileged, i.e., given precisely the permissions they require.

[...]

JEP 200 和 JEP 220 都是 查看全文