Re: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because SecurityManager is disabled
On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks <smarks@openjdk.org> wrote:
Enable the security manager in rmiregistry's launcher arguments.
As things stand, `rmiregsitry -J-Djava.security.manager` and `rmiregistry -J-Djava.security.manager=allow` are equivalent because rmiregistry sets the default SM. Some difference may be observed if someone is running rmiregistry with a custom system class loader set, or custom file system provider, or running it with a JVM TI agent that is looking at events between VMStart and VMInit but these seem somewhat obscure scenarios for a command line program If rmiregstry worked with ToolProvider then I think there would be more to discuss. If the final patch is to have the launcher set the default security manager then we may want to change RegistryImpl.createRegistry to fail if not set. The warning that is emitted for both cases is expected. JEP 411 is very clear that it there is no mechanism to suppress it. We may need to add a release note to document that rmiregistry will emit a warning a startup, that will at least be something to point at in the event that anyone asks or reports an issue. ------------- PR: https://git.openjdk.java.net/jdk18/pull/45
On Sun, 19 Dec 2021 07:37:19 GMT, Alan Bateman <alanb@openjdk.org> wrote:
Enable the security manager in rmiregistry's launcher arguments.
As things stand, `rmiregsitry -J-Djava.security.manager` and `rmiregistry -J-Djava.security.manager=allow` are equivalent because rmiregistry sets the default SM. Some difference may be observed if someone is running rmiregistry with a custom system class loader set, or custom file system provider, or running it with a JVM TI agent that is looking at events between VMStart and VMInit but these seem somewhat obscure scenarios for a command line program If rmiregstry worked with ToolProvider then I think there would be more to discuss. If the final patch is to have the launcher set the default security manager then we may want to change RegistryImpl.createRegistry to fail if not set.
The warning that is emitted for both cases is expected. JEP 411 is very clear that it there is no mechanism to suppress it. We may need to add a release note to document that rmiregistry will emit a warning a startup, that will at least be something to point at in the event that anyone asks or reports an issue.
In the same kind of PR (https://github.com/openjdk/jdk18/pull/53) for `jstatd` @AlanBateman writes:
This looks okay in that it is now worked exactly as it did in JDK 17.
And that PR uses `allow` as I have suggested here (to preserve existing behaviour). All the affected launchers should be fixed in the same consistent way. ------------- PR: https://git.openjdk.java.net/jdk18/pull/45
participants (2)
-
Alan Bateman
-
David Holmes