Re: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed [v18]
On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls wrote: >> JMX uses APIs related to the Security Mananger which are deprecated. Use of >> AccessControlContext will be removed when Security Manager is removed. >> >> Until then, updates are needed to not require setting >> -Djava.security.manager=allow to use JMX authentication. > > Kevin Walls has updated the pull request incrementally with one additional > commit since the last revision: > > braces Agreed that this is niche and will be short-lived, but I have added some SM-enabled runs with all permission policy for ThreadPoolAccTest.java and StartStopTest.java. These look trivial to add, and will be trivial to remove... Looking forward to more cleanup when we remove the SM-enabled paths. - PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2175956243
Re: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed [v18]
On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls wrote: >> JMX uses APIs related to the Security Mananger which are deprecated. Use of >> AccessControlContext will be removed when Security Manager is removed. >> >> Until then, updates are needed to not require setting >> -Djava.security.manager=allow to use JMX authentication. > > Kevin Walls has updated the pull request incrementally with one additional > commit since the last revision: > > braces I skimmed through the changes, much more readable now compared to some of the initial revisions. I kinda agree with one of the comments from a few days ago that if (allow) { .. } else { ..} is easier to read than putting the disallow case first. It's not a big deal as this code will be changed very soon to remove the SM path. As regards testing then I think the highest priority should be to default/no-SM case. We need to be confident that there are no regressions in JMX for this execution mode. We don't have of course want to regression for the SM case but that is a niche execution mode and not long for this world. - PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2175831168
Re: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed [v18]
On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls wrote: >> JMX uses APIs related to the Security Mananger which are deprecated. Use of >> AccessControlContext will be removed when Security Manager is removed. >> >> Until then, updates are needed to not require setting >> -Djava.security.manager=allow to use JMX authentication. > > Kevin Walls has updated the pull request incrementally with one additional > commit since the last revision: > > braces Yes, maybe we are light on testing with an SM actually enabled. AuthorizationTest is the key test here, and tests authenticated connections with user/role names. That is passing with no SM, SM allowed, and SM enabled with policy. I am testing ThreadPoolAccTest.java with SM enabled with an allPermission policy, as well as just SM allowed or not allowed. This is a good test as it exercises the Monitor class. This still works, will add it. Also, manual testing looks good to me: In problem builds of jdk 23, attaching with JMX using authentication results in: org.openjdk.kjdb.MyDebuggerException: getSubject is supported only if a security manager is allowed With this change, JMX attach using authentication works. A monitor role can correctly get refusals like: Caused by: java.lang.SecurityException: Access denied! Invalid access level for requested MBeanServer operation. at com.sun.jmx.remote.security.MBeanServerFileAccessController.checkAccess(MBeanServerFileAccessController.java:348) at com.sun.jmx.remote.security.MBeanServerFileAccessController.checkWrite(MBeanServerFileAccessController.java:240) at com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:469) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1520) ...and a control role is accepted (that's JMX simple security at work). Running the target with a SecurityManager, and attaching, I see e.g.: org.openjdk.kjdb.MyDebuggerException: access denied ("javax.management.MBeanPermission" "com.sun.management.internal.HotSpotThreadImpl#-[java.lang:type=Threading]" "isInstanceOf") ...which looks correct. Add a -Djava.security.policy=/my/all.policy which has allPermission, and connections work OK. Removing AllPermission from that policy, we get Exceptions again. This looks good. - PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2175801724
Re: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed [v18]
> JMX uses APIs related to the Security Mananger which are deprecated. Use of > AccessControlContext will be removed when Security Manager is removed. > > Until then, updates are needed to not require setting > -Djava.security.manager=allow to use JMX authentication. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: braces - Changes: - all: https://git.openjdk.org/jdk/pull/19624/files - new: https://git.openjdk.org/jdk/pull/19624/files/67aca736..384a3a19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=16-17 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19624.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624 PR: https://git.openjdk.org/jdk/pull/19624