Re: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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=19624=17 - incr: https://webrevs.openjdk.org/?repo=jdk=19624=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
