From kevinw at openjdk.org  Mon Jun 10 14:28:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 10 Jun 2024 14:28:34 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work when
 security manager not allowed
Message-ID: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>

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.

-------------

Commit messages:
 - Additional test combination, old getSubject call with sm=allow
 - Test updates
 - whitespace
 - Merge remote-tracking branch 'upstream/master' into 8333344_JMX_Subject
 - 8333344: JMX attaching of Subject does not work when security manager not allowed

Changes: https://git.openjdk.org/jdk/pull/19624/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333344
  Stats: 160 lines in 19 files changed: 109 ins; 10 del; 41 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

From kevinw at openjdk.org  Mon Jun 10 14:28:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 10 Jun 2024 14:28:34 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <SBjBDVRRebfJYnmP6rseRU7_gkPR7mIqzn03UlnLNTE=.a841c253-b66f-4ffa-bb64-746fc3dda266@github.com>

On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls <kevinw at openjdk.org> 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.

When SecurityManager is not permitted, which is the default, use the Subject.current() call.
If SM is permitted, due to -Djava.security.manager=allow then the old Subject.getSubject(AccessController.getContext()) call is used.

Tests are updated to not require -Djava.security.manager=allow and will test with and without that setting.

Also additionally update tests to use Subject.current(), but also have a setting to test the old Subject.getSubject(AccessController.getContext()) call with -Djava.security.manager=allow (see ThreadPoolAccTest and test/jdk/javax/management/remote/mandatory/passwordAuthenticator).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2158515271

From alanb at openjdk.org  Mon Jun 10 14:31:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jun 2024 14:31:12 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <98jFZxRQloFmqxvUlo20WiICow96XWt1ZiDkFsuj728=.760dcba6-ddd6-4e36-a59f-079b6dc414fe@github.com>

On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls <kevinw at openjdk.org> 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.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1634:

> 1632:                 } else {
> 1633:                     // We have ACC therefore SM is permitted, and Subject must be non-null:
> 1634:                     return Subject.doAs(subject, (PrivilegedExceptionAction<T>) () -> AccessController.doPrivileged((PrivilegedExceptionAction<T>) () -> wrappedClass.cast(mo.get()), acc));

This is not readable. If you create the PAEs explicitly then the casts will go away and it will be much easier to read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1633351429

From kevinw at openjdk.org  Mon Jun 10 15:37:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 10 Jun 2024 15:37:14 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed
In-Reply-To: <98jFZxRQloFmqxvUlo20WiICow96XWt1ZiDkFsuj728=.760dcba6-ddd6-4e36-a59f-079b6dc414fe@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <98jFZxRQloFmqxvUlo20WiICow96XWt1ZiDkFsuj728=.760dcba6-ddd6-4e36-a59f-079b6dc414fe@github.com>
Message-ID: <M1wScbpaNcD94838eWSIjN2YM9oNEkES-ibFtdTu8fc=.ae6538fc-9d69-478e-9f6b-7734e2af9d69@github.com>

On Mon, 10 Jun 2024 14:28:25 GMT, Alan Bateman <alanb at openjdk.org> 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.
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1634:
> 
>> 1632:                 } else {
>> 1633:                     // We have ACC therefore SM is permitted, and Subject must be non-null:
>> 1634:                     return Subject.doAs(subject, (PrivilegedExceptionAction<T>) () -> AccessController.doPrivileged((PrivilegedExceptionAction<T>) () -> wrappedClass.cast(mo.get()), acc));
> 
> This is not readable. If you create the PAEs explicitly then the casts will go away and it will be much easier to read.

Yes will simplify this!
This style was actually from the idea of moving to Subject.callAs, and nesting calls to keep the doPrivileged, but I don't think it will be necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1633455244

From kevinw at openjdk.org  Mon Jun 10 16:52:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 10 Jun 2024 16:52:26 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v2]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <KSfvEpU3M549RiJQk2XxvhO9YygBORGTxOz4S-uyG18=.413cd464-0762-4490-8597-7d78baaede7d@github.com>

> 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:

  More consistent style of calls and comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/22424a8e..d43f9a34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=00-01

  Stats: 12 lines in 1 file changed: 5 ins; 0 del; 7 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

From mullan at openjdk.org  Tue Jun 11 14:08:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Jun 2024 14:08:14 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v2]
In-Reply-To: <KSfvEpU3M549RiJQk2XxvhO9YygBORGTxOz4S-uyG18=.413cd464-0762-4490-8597-7d78baaede7d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <KSfvEpU3M549RiJQk2XxvhO9YygBORGTxOz4S-uyG18=.413cd464-0762-4490-8597-7d78baaede7d@github.com>
Message-ID: <XkkTDAn9-sZDr-0Z1t7G7_Gg5YJdsy6CD_Uqu8HztXs=.ae4dbf01-fd6b-47a1-b8ba-6e154f5e1288@github.com>

On Mon, 10 Jun 2024 16:52:26 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>   More consistent style of calls and comments.

A couple of comments so far; still reviewing.

test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 36:

> 34:  * @run main NotificationEmissionTest 1
> 35: 
> 36:  * @run main/othervm NotificationEmissionTest 1

Lines 34 & 36: is it necessary to run NotificationEmissionTest twice with and w/o `othervm`?

test/jdk/javax/management/remote/mandatory/passwordAuthenticator/SimpleStandard.java line 155:

> 153:      */
> 154:     private void checkSubject() {
> 155:          Subject subject = Boolean.getBoolean("SimpleStandard.useGetSubjectACC") ?

Nit, remove extra leading space.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19624#pullrequestreview-2110572609
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1634951807
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1634955377

From kevinw at openjdk.org  Tue Jun 11 16:18:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 16:18:24 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v2]
In-Reply-To: <XkkTDAn9-sZDr-0Z1t7G7_Gg5YJdsy6CD_Uqu8HztXs=.ae4dbf01-fd6b-47a1-b8ba-6e154f5e1288@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <KSfvEpU3M549RiJQk2XxvhO9YygBORGTxOz4S-uyG18=.413cd464-0762-4490-8597-7d78baaede7d@github.com>
 <XkkTDAn9-sZDr-0Z1t7G7_Gg5YJdsy6CD_Uqu8HztXs=.ae4dbf01-fd6b-47a1-b8ba-6e154f5e1288@github.com>
Message-ID: <Bbg-eYVNZPzkPnXm9JM4l_Od4FJU9ms__T68Y3x8TYw=.3dd99d69-afc1-454a-86d4-5355fab32464@github.com>

On Tue, 11 Jun 2024 14:02:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More consistent style of calls and comments.
>
> test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 36:
> 
>> 34:  * @run main NotificationEmissionTest 1
>> 35: 
>> 36:  * @run main/othervm NotificationEmissionTest 1
> 
> Lines 34 & 36: is it necessary to run NotificationEmissionTest twice with and w/o `othervm`?

It's unnecessary, thanks.

> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/SimpleStandard.java line 155:
> 
>> 153:      */
>> 154:     private void checkSubject() {
>> 155:          Subject subject = Boolean.getBoolean("SimpleStandard.useGetSubjectACC") ?
> 
> Nit, remove extra leading space.

got it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635157731
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635157877

From kevinw at openjdk.org  Tue Jun 11 16:18:23 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 16:18:23 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>

> 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:

  Sean comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/d43f9a34..56f9111e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=01-02

  Stats: 5 lines in 2 files changed: 1 ins; 2 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

From weijun at openjdk.org  Tue Jun 11 17:07:16 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Jun 2024 17:07:16 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
Message-ID: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>

On Tue, 11 Jun 2024 16:18:23 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>   Sean comments

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1301:

> 1299:                     }
> 1300:             };
> 1301:             if (acc == null) {

This is a comment to all the code changes in this PR. I would recommend we make use of the `allowSecurityManager()` call everywhere when the behavior is different, like this:

if (SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
    if (acc == null)
        return action.run();
    else
        return AccessController.doPrivileged(action, acc);
} else {
    if (subject == null)
        return action.run();
    else
        return Subject.doAs(subject, action);
}

This makes me much more confident.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1436:

> 1434:             } else {
> 1435:                 // ACC is present, we have a Subject and SM is permitted:
> 1436:                 return AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> Subject.doAs(subject, op), acc);

Why is it necessary to call both `doAs` and `doPrivileged`?

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1438:

> 1436:                 return AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> Subject.doAs(subject, op), acc);
> 1437:             }
> 1438:         } catch (PrivilegedActionException pe) {

What is this catch block for? The cause of a `PrivilegedActionException` should not be a unchecked exception.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1453:

> 1451:                 throw new RuntimeException(cause);
> 1452:             }
> 1453:         } catch (Exception e) {

Is this block only for the `op.run()` line? Why not keep the old try-catch block around it and move the logic here?

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1633:

> 1631:                     }
> 1632:                 } else {
> 1633:                     // ACC is present, we have a Subject and SM is permitted:

While extract the `action` variable? The old code on lines 1590-1592 has no problem.

src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 350:

> 348:     @SuppressWarnings("removal")
> 349:     private Subject getSubject() {
> 350:         Subject subject = null;

Just call `Subject.current()`. When SM is allowed, it is equivalent to `getSubject(AccessController.getContext())`.

src/java.management/share/classes/javax/management/monitor/Monitor.java line 718:

> 716:             // The monitor tasks will be executed within this context.
> 717:             //
> 718:             subject = Subject.current();

If `subject` is only used when SM is not allowed, you can put the assignment above to the else if next line.

src/java.management/share/classes/javax/management/monitor/Monitor.java line 1541:

> 1539:             if (ac == null) {
> 1540:                 // No SecurityManager:
> 1541:                 Subject.doAs(s, action);

What if `s` is null?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635218675
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635202721
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635205035
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635206172
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635208088
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635209275
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635212375
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635213527

From kevinw at openjdk.org  Tue Jun 11 18:07:53 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 18:07:53 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
Message-ID: <Gg34s2AIlChqCxi942j__gd43RoyiDfMIt8bIdoJb7I=.759c6e64-00ff-408c-90b0-76d530958a7d@github.com>

On Tue, 11 Jun 2024 17:03:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1301:
> 
>> 1299:                     }
>> 1300:             };
>> 1301:             if (acc == null) {
> 
> This is a comment to all the code changes in this PR. I would recommend we make use of the `allowSecurityManager()` call everywhere when the behavior is different, like this:
> 
> if (SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>     if (acc == null)
>         return action.run();
>     else
>         return AccessController.doPrivileged(action, acc);
> } else {
>     if (subject == null)
>         return action.run();
>     else
>         return Subject.doAs(subject, action);
> }
> 
> This makes me much more confident.

Thanks I'll go through the above comments and update - some of the changes I see are unnecessary and from when I was trying migrating to callAs, and doPrivileged, and yes they can be simpler.

On the allowSecurityMananger check: 
If we check in e.g. RMIConnectionImpl constructor, and if SM is allowed we assign an ACC.
Later, we know if we have a non-null ACC then SM is allowed.  Are you saying we should then check allowSecurityManager  again?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635291389

From weijun at openjdk.org  Tue Jun 11 19:04:17 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Jun 2024 19:04:17 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <Gg34s2AIlChqCxi942j__gd43RoyiDfMIt8bIdoJb7I=.759c6e64-00ff-408c-90b0-76d530958a7d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
 <Gg34s2AIlChqCxi942j__gd43RoyiDfMIt8bIdoJb7I=.759c6e64-00ff-408c-90b0-76d530958a7d@github.com>
Message-ID: <ZP4s55UH9ubCxKJ2eDbjy5c6YGGbSalNWY7dCrw3WrU=.f22b8d9e-47ff-42f8-af42-1b3d46754ff6@github.com>

On Tue, 11 Jun 2024 18:04:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1301:
>> 
>>> 1299:                     }
>>> 1300:             };
>>> 1301:             if (acc == null) {
>> 
>> This is a comment to all the code changes in this PR. I would recommend we make use of the `allowSecurityManager()` call everywhere when the behavior is different, like this:
>> 
>> if (SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>>     if (acc == null)
>>         return action.run();
>>     else
>>         return AccessController.doPrivileged(action, acc);
>> } else {
>>     if (subject == null)
>>         return action.run();
>>     else
>>         return Subject.doAs(subject, action);
>> }
>> 
>> This makes me much more confident.
>
> Thanks I'll go through the above comments and update - some of the changes I see are unnecessary and from when I was trying migrating to callAs, and doPrivileged, and yes they can be simpler.
> 
> On the allowSecurityMananger check: 
> If we check in e.g. RMIConnectionImpl constructor, and if SM is allowed we assign an ACC.
> Later, we know if we have a non-null ACC then SM is allowed.  Are you saying we should then check allowSecurityManager  again?

Yes, the check is very light and it makes sure the old code and new code are fully separated. It's safe since it can be quite easy to see when SM is allowed there is no behavior change. In the near future when we finally remove the SM it will also be simple to remove the old code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635352326

From mullan at openjdk.org  Tue Jun 11 21:01:17 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Jun 2024 21:01:17 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
Message-ID: <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>

On Tue, 11 Jun 2024 16:51:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1436:
> 
>> 1434:             } else {
>> 1435:                 // ACC is present, we have a Subject and SM is permitted:
>> 1436:                 return AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> Subject.doAs(subject, op), acc);
> 
> Why is it necessary to call both `doAs` and `doPrivileged`?

Can you just call `AccessController.doPrivileged(op, acc)` as in the original code? `Subject.doAs` requires a permission, which is why I assume you are wrapping it in a `doPrivileged` but you are asserting all of the permissions of the `java.management` module, which means you probably want to use limited doPriv and only assert the `getSubject` permission but that is getting complicated. I'd go back to the original call as it should work in the SM allow case.

> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 350:
> 
>> 348:     @SuppressWarnings("removal")
>> 349:     private Subject getSubject() {
>> 350:         Subject subject = null;
> 
> Just call `Subject.current()`. When SM is allowed, it is equivalent to `getSubject(AccessController.getContext())`.

For the same reason you should be able to just call `Subject.current` in the tests. I don't think you need the `SimpleStandard.useGetSubjectACC` property to toggle the testing of either old or replacement APIs as long as the test has runs in both SM allow and disallow (i.e., no SM prop set) modes. Would you agree Weijun?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635475145
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635449088

From kevinw at openjdk.org  Wed Jun 12 11:52:22 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 11:52:22 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
Message-ID: <9xkQA1A3p199VLywmpejXTJoRNmWEFYlAZs2xwU66YM=.5384477f-58db-44e5-af00-a9b4c33d190b@github.com>

On Tue, 11 Jun 2024 16:59:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> src/java.management/share/classes/javax/management/monitor/Monitor.java line 1541:
> 
>> 1539:             if (ac == null) {
>> 1540:                 // No SecurityManager:
>> 1541:                 Subject.doAs(s, action);
> 
> What if `s` is null?

Subject.doAs accepts a null Subject, so that's OK?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636324060

From kevinw at openjdk.org  Wed Jun 12 12:59:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 12:59:14 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
 <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>
Message-ID: <PFV4VRqZZySQbDbgrvJx-FsZulLoQJ5RmDdK7Z7sHWo=.3d954a5b-7c37-4db7-97dd-c22e81bac1bb@github.com>

On Tue, 11 Jun 2024 20:58:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1436:
>> 
>>> 1434:             } else {
>>> 1435:                 // ACC is present, we have a Subject and SM is permitted:
>>> 1436:                 return AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> Subject.doAs(subject, op), acc);
>> 
>> Why is it necessary to call both `doAs` and `doPrivileged`?
>
> Can you just call `AccessController.doPrivileged(op, acc)` as in the original code? `Subject.doAs` requires a permission, which is why I assume you are wrapping it in a `doPrivileged` but you are asserting all of the permissions of the `java.management` module, which means you probably want to use limited doPriv and only assert the `getSubject` permission but that is getting complicated. I'd go back to the original call as it should work in the SM allow case.

Yes, this can be simpler, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636417433

From kevinw at openjdk.org  Wed Jun 12 12:59:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 12:59:16 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
Message-ID: <3rT8VL9apE_LSNZucc9IuqST8Pcr7VQgxBGxbK-v5mU=.b9fc25a1-90a3-41bc-88e4-a7c12560d457@github.com>

On Tue, 11 Jun 2024 16:53:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1438:
> 
>> 1436:                 return AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> Subject.doAs(subject, op), acc);
>> 1437:             }
>> 1438:         } catch (PrivilegedActionException pe) {
> 
> What is this catch block for? The cause of a `PrivilegedActionException` should not be a unchecked exception.

Looks like the catch of PrivilegedActionException is no longer necessary, will be removed.
Was from from previously using a different doAs or call which needed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636417022

From kevinw at openjdk.org  Wed Jun 12 14:01:40 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 14:01:40 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v4]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>

> 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:

  udpates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/56f9111e..422011e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=02-03

  Stats: 35 lines in 2 files changed: 6 ins; 23 del; 6 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

From kevinw at openjdk.org  Wed Jun 12 14:01:41 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 14:01:41 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
Message-ID: <BT09RXeaBTpejL4RPJGq4oiqeYmiP9JHCk8_JQQy0S4=.a2d629f4-eaee-4d9e-b53a-2f11cef6f697@github.com>

On Tue, 11 Jun 2024 16:55:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1633:
> 
>> 1631:                     }
>> 1632:                 } else {
>> 1633:                     // ACC is present, we have a Subject and SM is permitted:
> 
> While extract the `action` variable? The old code on lines 1590-1592 has no problem.

OK I can make this more like the original.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636515151

From kevinw at openjdk.org  Wed Jun 12 14:09:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 14:09:16 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
 <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>
Message-ID: <tKMzL3ItOgRgLgi3gpfxeJhF1giLbogAKqEz0aizuxw=.36362158-215d-446e-8636-f22d88e63a7a@github.com>

On Tue, 11 Jun 2024 20:31:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 350:
>> 
>>> 348:     @SuppressWarnings("removal")
>>> 349:     private Subject getSubject() {
>>> 350:         Subject subject = null;
>> 
>> Just call `Subject.current()`. When SM is allowed, it is equivalent to `getSubject(AccessController.getContext())`.
>
> For the same reason you should be able to just call `Subject.current` in the tests. I don't think you need the `SimpleStandard.useGetSubjectACC` property to toggle the testing of either old or replacement APIs as long as the test has runs in both SM allow and disallow (i.e., no SM prop set) modes. Would you agree Weijun?

I thought there was a comment elsewhere suggesting using SM=allow to test with Subject.getSubject() and Subject.current(), and when SM not allowed, to only use Subject.current() ?
That was the reason for the property in the tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636536113

From dfuchs at openjdk.org  Wed Jun 12 14:26:14 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Jun 2024 14:26:14 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v4]
In-Reply-To: <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
Message-ID: <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>

On Wed, 12 Jun 2024 14:01:40 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>   udpates

test/jdk/javax/management/remote/mandatory/notif/policy.negative line 7:

> 5:     permission javax.management.MBeanPermission "[domain:type=NB,name=2]", "addNotificationListener";
> 6:     permission javax.management.MBeanPermission "*", "removeNotificationListener";
> 7:     permission javax.security.auth.AuthPermission "doAs";

I suspect that this means a doPrivileged is missing somewhere. We should not require the application to posess new permissions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636573141

From alanb at openjdk.org  Wed Jun 12 14:34:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Jun 2024 14:34:15 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v4]
In-Reply-To: <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
 <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>
Message-ID: <af8MlY3bDlAOMVyit3E6fI-3nw5Vom8FuIBEJhj2bpA=.672f2f75-3c9f-4b09-8c5a-86c79429af6f@github.com>

On Wed, 12 Jun 2024 14:23:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   udpates
>
> test/jdk/javax/management/remote/mandatory/notif/policy.negative line 7:
> 
>> 5:     permission javax.management.MBeanPermission "[domain:type=NB,name=2]", "addNotificationListener";
>> 6:     permission javax.management.MBeanPermission "*", "removeNotificationListener";
>> 7:     permission javax.security.auth.AuthPermission "doAs";
> 
> I suspect that this means a doPrivileged is missing somewhere. We should not require the application to posess new permissions.

I think Daniel is right, can you remove this permission and paste in the debug output to see where this is happening?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636587055

From kevinw at openjdk.org  Wed Jun 12 14:48:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 14:48:13 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v4]
In-Reply-To: <af8MlY3bDlAOMVyit3E6fI-3nw5Vom8FuIBEJhj2bpA=.672f2f75-3c9f-4b09-8c5a-86c79429af6f@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
 <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>
 <af8MlY3bDlAOMVyit3E6fI-3nw5Vom8FuIBEJhj2bpA=.672f2f75-3c9f-4b09-8c5a-86c79429af6f@github.com>
Message-ID: <7L_k1ykC2z-E0uLtcdoycnvlmmBdmRc1vgr4LcbX_-E=.90918413-2ac0-4ef0-b995-3db004a028ca@github.com>

On Wed, 12 Jun 2024 14:31:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/javax/management/remote/mandatory/notif/policy.negative line 7:
>> 
>>> 5:     permission javax.management.MBeanPermission "[domain:type=NB,name=2]", "addNotificationListener";
>>> 6:     permission javax.management.MBeanPermission "*", "removeNotificationListener";
>>> 7:     permission javax.security.auth.AuthPermission "doAs";
>> 
>> I suspect that this means a doPrivileged is missing somewhere. We should not require the application to posess new permissions.
>
> I think Daniel is right, can you remove this permission and paste in the debug output to see where this is happening?

Hmm I may have fixed that since changing the policy files, as I'm not seeing the problem without that AuthPermission any more.  Am just retesting everything before updating this...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636613493

From dfuchs at openjdk.org  Wed Jun 12 14:58:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Jun 2024 14:58:11 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v4]
In-Reply-To: <7L_k1ykC2z-E0uLtcdoycnvlmmBdmRc1vgr4LcbX_-E=.90918413-2ac0-4ef0-b995-3db004a028ca@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
 <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>
 <af8MlY3bDlAOMVyit3E6fI-3nw5Vom8FuIBEJhj2bpA=.672f2f75-3c9f-4b09-8c5a-86c79429af6f@github.com>
 <7L_k1ykC2z-E0uLtcdoycnvlmmBdmRc1vgr4LcbX_-E=.90918413-2ac0-4ef0-b995-3db004a028ca@github.com>
Message-ID: <EA1pdX9zphjC043LsFOLmZL30ZCp2h_TvIZbSiXZ48w=.a615548a-7d3f-4588-a094-18403fe17d0e@github.com>

On Wed, 12 Jun 2024 14:44:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I think Daniel is right, can you remove this permission and paste in the debug output to see where this is happening?
>
> Hmm I may have fixed that since changing the policy files, as I'm not seeing the problem without that AuthPermission any more.  Am just retesting everything before updating this...

(Same with other policy files in which the permission was added of course)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636634416

From kevinw at openjdk.org  Wed Jun 12 16:07:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 16:07:29 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v5]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <zv6E7fQk-eDePVNpFwzU-HQ9KMz1ZOpbEFVi7dbfx-U=.99c2f9ac-22a3-49bc-b880-e7b8e2e927dd@github.com>

> 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:

   Undo test policy updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/422011e4..9664bef6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=03-04

  Stats: 5 lines in 3 files changed: 0 ins; 5 del; 0 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

From kevinw at openjdk.org  Wed Jun 12 16:11:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 16:11:28 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v6]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>

> 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:

   Undo test policy updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/9664bef6..6f072338

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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

From kevinw at openjdk.org  Wed Jun 12 16:14:12 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 16:14:12 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v4]
In-Reply-To: <EA1pdX9zphjC043LsFOLmZL30ZCp2h_TvIZbSiXZ48w=.a615548a-7d3f-4588-a094-18403fe17d0e@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
 <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>
 <af8MlY3bDlAOMVyit3E6fI-3nw5Vom8FuIBEJhj2bpA=.672f2f75-3c9f-4b09-8c5a-86c79429af6f@github.com>
 <7L_k1ykC2z-E0uLtcdoycnvlmmBdmRc1vgr4LcbX_-E=.90918413-2ac0-4ef0-b995-3db004a028ca@github.com>
 <EA1pdX9zphjC043LsFOLmZL30ZCp2h_TvIZbSiXZ48w=.a615548a-7d3f-4588-a094-18403fe17d0e@github.com>
Message-ID: <1eHH4vDatJuI7ltL0BrDz0bxGZt-6dZIbVrhvXnkPoM=.c5bcde86-60dc-40af-8c74-0bf0e36a3e84@github.com>

On Wed, 12 Jun 2024 14:55:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hmm I may have fixed that since changing the policy files, as I'm not seeing the problem without that AuthPermission any more.  Am just retesting everything before updating this...
>
> (Same with other policy files in which the permission was added of course)

Yes these no longer seem needed.  I added them in response to failures in an earlier version of the change, thanks for spotting this, I've undone the policy changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636753776

From dfuchs at openjdk.org  Wed Jun 12 16:56:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Jun 2024 16:56:15 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v6]
In-Reply-To: <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
Message-ID: <nXxazFJyr4lQazQITKV2BQI0A8mG2AJrpGtZQPF2_QQ=.5a5ec88c-6063-46d1-b067-cba2d45199b9@github.com>

On Wed, 12 Jun 2024 16:11:28 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>    Undo test policy updates

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1445:

> 1443:             } else {
> 1444:                 throw new PrivilegedActionException(e);
> 1445:             }

I assume there no chance that `Exception e` may already be a `PrivilegedActionException` here. You coud avoid casts by using instanceof patterns.

Suggestion:

            if (e instanceof RuntimeException rte) {
                throw  rte;
            } else {
                throw new PrivilegedActionException(e);
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636791497

From mullan at openjdk.org  Wed Jun 12 21:06:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Jun 2024 21:06:14 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v6]
In-Reply-To: <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
Message-ID: <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>

On Wed, 12 Jun 2024 16:11:28 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>    Undo test policy updates

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1304:

> 1302:                 // No ACC, therefore no SM. May have a Subject:
> 1303:                 if (subject != null) {
> 1304:                     return Subject.doAs(subject, action);

Is it ever possible for subject to be `null` (passed in as `null` to the constructor) and an SM to be enabled? If so, then the call above to `Subject.doAs` would trigger a permission for an `AuthPermission("doAs")` permission. (This also may have been the case you were seeing in tests).

I think following Weijun's advice above is cleaner and safer, so you do one or the other depending on the allowSM setting, and not whether certain variables are null or not.

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 304:

> 302:     }
> 303: 
> 304:     @SuppressWarnings("removal")

Is this annotation needed? I see you have one below.

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 312:

> 310:             @SuppressWarnings("removal")
> 311:             final AccessControlContext acc = AccessController.getContext();
> 312:             //@SuppressWarnings("removal")

Remove this line?

src/java.management/share/classes/javax/management/monitor/Monitor.java line 1543:

> 1541:                 // No SecurityManager:
> 1542:                 Subject.doAs(s, action); // s is permitted to be null
> 1543:             } else {

Even though ac should never be null, I would keep the original check for ac == null inside the SM code path to be safe and consistent with the original code, and use only call doAs if allowSM is false, so like:


if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
    // No SecurityManager:
    Subject.doAs(s, action); // s is permitted to be null
} else {
    if (ac == null) {
        throw new SecurityException("AccessControlContext cannot be null");
    }
    // ACC means SM is permitted.
    AccessController.doPrivileged(action, ac);
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637086418
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637060238
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637060517
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637073809

From mullan at openjdk.org  Wed Jun 12 21:06:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Jun 2024 21:06:14 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <tKMzL3ItOgRgLgi3gpfxeJhF1giLbogAKqEz0aizuxw=.36362158-215d-446e-8636-f22d88e63a7a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
 <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>
 <tKMzL3ItOgRgLgi3gpfxeJhF1giLbogAKqEz0aizuxw=.36362158-215d-446e-8636-f22d88e63a7a@github.com>
Message-ID: <iV7z5vyop0OZ8GdczZSxblBpEqdhOR8nMnw-aLOiA0U=.60e5acb2-ebb8-4c30-91df-02bc9cd0ea71@github.com>

On Wed, 12 Jun 2024 14:06:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> For the same reason you should be able to just call `Subject.current` in the tests. I don't think you need the `SimpleStandard.useGetSubjectACC` property to toggle the testing of either old or replacement APIs as long as the test has runs in both SM allow and disallow (i.e., no SM prop set) modes. Would you agree Weijun?
>
> I thought there was a comment elsewhere suggesting using SM=allow to test with Subject.getSubject() and Subject.current(), and when SM not allowed, to only use Subject.current() ?
> That was the reason for the property in the tests.

Um, yes that was my comment :) Ok, let's leave the tests as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637054347

From kevinw at openjdk.org  Thu Jun 13 10:27:40 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 10:27:40 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v7]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <9f_IZR1qUiOuViO8nPYmL-CexyVL4jVw3zYgbA_OKMQ=.6b72482a-c04f-475c-917a-686773878ce2@github.com>

> 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:

  Annotation in checkAccess

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/6f072338..32f52c52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 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

From kevinw at openjdk.org  Thu Jun 13 10:27:40 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 10:27:40 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v6]
In-Reply-To: <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
 <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
Message-ID: <j4z7TNP7Gm72-0hSG-9GiwsKlYz74pD0Y3LGBH6oonY=.35c77de6-d145-42ef-a09f-e8503cb6cd1e@github.com>

On Wed, 12 Jun 2024 20:42:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Undo test policy updates
>
> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 312:
> 
>> 310:             @SuppressWarnings("removal")
>> 311:             final AccessControlContext acc = AccessController.getContext();
>> 312:             //@SuppressWarnings("removal")
> 
> Remove this line?

Now the assignment to Subject is split into two alternatives, this annotation doesn't work (without the variable declaration).
Yes I can remove this and can go with just one annotation for the method.
I am expecting to remove the deprecated methods here in a followup change after SM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637973185

From kevinw at openjdk.org  Thu Jun 13 13:07:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 13:07:38 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v6]
In-Reply-To: <nXxazFJyr4lQazQITKV2BQI0A8mG2AJrpGtZQPF2_QQ=.5a5ec88c-6063-46d1-b067-cba2d45199b9@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
 <nXxazFJyr4lQazQITKV2BQI0A8mG2AJrpGtZQPF2_QQ=.5a5ec88c-6063-46d1-b067-cba2d45199b9@github.com>
Message-ID: <sRtC0SCJDl4SQEqfnRXzZNxS_tSMS-Eke8kPAguhvlc=.a3243221-0aeb-496f-a5e7-e8a6890bbac9@github.com>

On Wed, 12 Jun 2024 16:41:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Undo test policy updates
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1445:
> 
>> 1443:             } else {
>> 1444:                 throw new PrivilegedActionException(e);
>> 1445:             }
> 
> I assume there no chance that `Exception e` may already be a `PrivilegedActionException` here. You coud avoid casts by using instanceof patterns.
> 
> Suggestion:
> 
>             if (e instanceof RuntimeException rte) {
>                 throw  rte;
>             } else {
>                 throw new PrivilegedActionException(e);
>             }

ok yes will do that.  SecurityException was another carryover from before simplifying the updated calls, think it's no longer needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1638181708

From kevinw at openjdk.org  Thu Jun 13 13:07:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 13:07:38 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v8]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <7RTa-HMjPLmHbLnrBLjdk4xNg-xc5fvJpQ7o2EceSbs=.b5b59386-71f7-414b-a40d-37e1ba7141fc@github.com>

> 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:

  Exception handling per Daniel comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/32f52c52..1ad97750

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=06-07

  Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 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

From kevinw at openjdk.org  Thu Jun 13 13:39:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 13:39:25 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v9]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <YwvOPk8JDr_75MVpgAdFttbjdllt73WQCwBo8h_uSGM=.83dbf3f3-e6f5-4a48-9627-808477368fa4@github.com>

> 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:

  ServerNotifForwarder getSubject update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/1ad97750..f70047a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=07-08

  Stats: 5 lines in 1 file changed: 0 ins; 3 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

From kevinw at openjdk.org  Thu Jun 13 20:54:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 20:54:25 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v10]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>

> 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:

  Separate SM allowed and not allowed cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/f70047a4..09c2e38f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=08-09

  Stats: 52 lines in 1 file changed: 31 ins; 8 del; 13 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

From kevinw at openjdk.org  Thu Jun 13 20:57:19 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 20:57:19 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v3]
In-Reply-To: <ZP4s55UH9ubCxKJ2eDbjy5c6YGGbSalNWY7dCrw3WrU=.f22b8d9e-47ff-42f8-af42-1b3d46754ff6@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
 <Gg34s2AIlChqCxi942j__gd43RoyiDfMIt8bIdoJb7I=.759c6e64-00ff-408c-90b0-76d530958a7d@github.com>
 <ZP4s55UH9ubCxKJ2eDbjy5c6YGGbSalNWY7dCrw3WrU=.f22b8d9e-47ff-42f8-af42-1b3d46754ff6@github.com>
Message-ID: <MUzM9SZNcW0eWNXIXnhh_UEZQNY-RXyO7DBUHfYhdRU=.ba2b03e2-02ca-47b9-830c-f1dce08d29d5@github.com>

On Tue, 11 Jun 2024 19:01:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Thanks I'll go through the above comments and update - some of the changes I see are unnecessary and from when I was trying migrating to callAs, and doPrivileged, and yes they can be simpler.
>> 
>> On the allowSecurityMananger check: 
>> If we check in e.g. RMIConnectionImpl constructor, and if SM is allowed we assign an ACC.
>> Later, we know if we have a non-null ACC then SM is allowed.  Are you saying we should then check allowSecurityManager  again?
>
> Not "then check" but "first check", as shown in my example above. I understand you can infer whether SM is allowed by looking at the values if `acc` and `subject`, but IMO it's not worth doing. The check is very light and this coding style makes sure the old code and new code are cleanly separated. It's easy to code because you don't modify existing code and only add new code in else blocks. In the near future when we finally remove the SM it will also be simple to remove old code.

I'm trying that out in this update.  It looks OK 8-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1638932678

From kevinw at openjdk.org  Fri Jun 14 10:18:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 10:18:26 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v6]
In-Reply-To: <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
 <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
Message-ID: <CgpksYGeTTwXCgwafY7b1MKTXRWfO_mwaC3bjlt-GCs=.3aecbacb-b5a0-4cbe-9c12-5848f81d4a42@github.com>

On Wed, 12 Jun 2024 21:03:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Undo test policy updates
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1304:
> 
>> 1302:                 // No ACC, therefore no SM. May have a Subject:
>> 1303:                 if (subject != null) {
>> 1304:                     return Subject.doAs(subject, action);
> 
> Is it ever possible for acc to be `null` and `subject` not `null` and an SM to be enabled? Doesn't look like it, but if it ever could be, then the call above to `Subject.doAs` would trigger a permission check for an `AuthPermission("doAs")` permission.
> 
> I think following Weijun's advice above is cleaner and safer, so you do one or the other depending on the allowSM setting, and not whether certain variables are null or not.

Right, the only possible assignment to acc in this file is if we were given a Subject, and SM is permitted.

In future there will be a Subject, which can be null.  While we handle SM, we still use the ACC if RMIConnectionImpl was created with a Subject.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639610678

From weijun at openjdk.org  Fri Jun 14 12:12:16 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Jun 2024 12:12:16 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v10]
In-Reply-To: <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
Message-ID: <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>

On Thu, 13 Jun 2024 20:54:25 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>   Separate SM allowed and not allowed cases

I don't quite understand why there is no more `noPermissionsACC` in `Monotor.java`. This looks like the only behavior change when SM is allowed. The other source change looks fine to me.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1461:

> 1459:                 throw rte;
> 1460:             } else {
> 1461:                 throw new PrivilegedActionException(e);

The 4 lines above seems unnecessary now. Plus, do not wrap `PrivilegedActionException` inside `PrivilegedActionException`.

src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 353:

> 351:         } else {
> 352:             return Subject.getSubject(AccessController.getContext());
> 353:         }

`Subject.current()` should work for both cases. See the impl of it.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19624#pullrequestreview-2118220033
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639720192
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639721194

From kevinw at openjdk.org  Fri Jun 14 12:44:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 12:44:13 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v10]
In-Reply-To: <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
Message-ID: <cp-kNjl5sDRtOtdqgru1Vvs7zS3cQ4yq1lAnzQlrBXw=.e09c9e03-46b5-4fca-856d-cc064f09e495@github.com>

On Fri, 14 Jun 2024 12:09:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I don't quite understand why there is no more `noPermissionsACC` in `Monotor.java`. This looks like the only behavior change when SM is allowed. The other source change looks fine to me.

Does noPermissionsACC add anything?  Maybe I'm rushing the removal of ACCs where I can.

Start sets acc to the current context (when SM permitted, use Subject otherwise)
Set acc to noPermissionsACC when stop is called (or forget the Subject).

acc is accessed within the run method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2167949489

From kevinw at openjdk.org  Fri Jun 14 12:47:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 12:47:13 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v10]
In-Reply-To: <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
Message-ID: <KeRilLtCKTM3jP18PozO7NI_Ieo-_uh-3mWO27Rt1oQ=.756806c0-5f3b-4ec2-879e-fdec75ff85ad@github.com>

On Fri, 14 Jun 2024 12:04:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Separate SM allowed and not allowed cases
>
> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 353:
> 
>> 351:         } else {
>> 352:             return Subject.getSubject(AccessController.getContext());
>> 353:         }
> 
> `Subject.current()` should work for both cases. See the impl of it.

ok!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639766973

From kevinw at openjdk.org  Fri Jun 14 13:14:20 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 13:14:20 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v10]
In-Reply-To: <KeRilLtCKTM3jP18PozO7NI_Ieo-_uh-3mWO27Rt1oQ=.756806c0-5f3b-4ec2-879e-fdec75ff85ad@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
 <KeRilLtCKTM3jP18PozO7NI_Ieo-_uh-3mWO27Rt1oQ=.756806c0-5f3b-4ec2-879e-fdec75ff85ad@github.com>
Message-ID: <30Q_v5zgWDNzJUXQo5uBAih3kIK-nLIVAS0_xF3XMoM=.aa810cbb-7e2e-4820-8639-1f910f3aa8e1@github.com>

On Fri, 14 Jun 2024 12:44:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 353:
>> 
>>> 351:         } else {
>>> 352:             return Subject.getSubject(AccessController.getContext());
>>> 353:         }
>> 
>> `Subject.current()` should work for both cases. See the impl of it.
>
> It will work to get the Subject yes.
> Do I not need the SM-enabled case, in case there some complex ACC in place? (combiner)

OK if it was actually getting specifically the ACC to use it maybe, but this just needs to resolve a Subject.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639806380

From kevinw at openjdk.org  Fri Jun 14 13:18:43 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 13:18:43 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v11]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <D5aPpZ1ztgkqOrAsBLdKwhswV1LaZq768JnTrlTL-_0=.df10967f-337d-4a59-92ed-0f61ce7afcc2@github.com>

> 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:

  ServerNotifForwarder simplification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/09c2e38f..242af991

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=09-10

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 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

From kevinw at openjdk.org  Fri Jun 14 13:32:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 13:32:35 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v12]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <B6JqYnJx2aAVySUD-ta0R33GCCa9UEFN8KUJ8MPZ7rQ=.a7d36422-1323-4a0a-9215-fe05a48d2942@github.com>

> 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:

  Monitor update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/242af991..d5f68b02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=10-11

  Stats: 5 lines in 1 file changed: 3 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

From kevinw at openjdk.org  Fri Jun 14 13:32:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 13:32:35 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v6]
In-Reply-To: <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
 <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
Message-ID: <PeQtD6VTA4AfMW-PkeciZpCfvP7LVR3Pq23bHz-RKfE=.81507ef5-4981-4061-b32f-447748ac1a36@github.com>

On Wed, 12 Jun 2024 20:52:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Undo test policy updates
>
> src/java.management/share/classes/javax/management/monitor/Monitor.java line 1543:
> 
>> 1541:                 // No SecurityManager:
>> 1542:                 Subject.doAs(s, action); // s is permitted to be null
>> 1543:             } else {
> 
> Even though ac should never be null, I would keep the original check for ac == null inside the SM code path to be safe and consistent with the original code, and use only call doAs if allowSM is false, so like:
> 
> 
> if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>     // No SecurityManager:
>     Subject.doAs(s, action); // s is permitted to be null
> } else {
>     if (ac == null) {
>         throw new SecurityException("AccessControlContext cannot be null");
>     }
>     // ACC means SM is permitted.
>     AccessController.doPrivileged(action, ac);
> }

ok done!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639833457

From kevinw at openjdk.org  Fri Jun 14 14:03:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 14:03:14 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v10]
In-Reply-To: <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
Message-ID: <5q2H_Fgz9nY_ykqrqhsfSXv8zQgpfkEOmdUpaAwN3Q0=.d58059e5-d408-4356-824d-413eda97a347@github.com>

On Fri, 14 Jun 2024 12:03:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Separate SM allowed and not allowed cases
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1461:
> 
>> 1459:                 throw rte;
>> 1460:             } else {
>> 1461:                 throw new PrivilegedActionException(e);
> 
> The 4 lines above seems unnecessary now. Plus, do not wrap `PrivilegedActionException` inside `PrivilegedActionException`.

It needs to recognise and throw RuntimeException so that a SecurityException isn't wrapped in a PrivilegedActionException (which gets caught by those blocks of code which call extractException(pe) and  look at what Exception it contains).

(test/jdk/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java tests this)

I can add a check to make sure PrivilgedActionException doesn't get wrapped.  Daniel I think mentioned this also.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639876260

From weijun at openjdk.org  Fri Jun 14 14:51:18 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Jun 2024 14:51:18 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v10]
In-Reply-To: <cp-kNjl5sDRtOtdqgru1Vvs7zS3cQ4yq1lAnzQlrBXw=.e09c9e03-46b5-4fca-856d-cc064f09e495@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
 <cp-kNjl5sDRtOtdqgru1Vvs7zS3cQ4yq1lAnzQlrBXw=.e09c9e03-46b5-4fca-856d-cc064f09e495@github.com>
Message-ID: <ALogI3wbbzp9cQ-2KJKwXjcPLsWa5wkqUdX8N5qgCyc=.ff71b0c6-ba82-4231-867f-3b88b9497db8@github.com>

On Fri, 14 Jun 2024 12:41:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Does noPermissionsACC add anything?

I don't know. My principal for this code change is that nothing is changed for the SM-is-allowed case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2168203868

From weijun at openjdk.org  Fri Jun 14 14:54:22 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Jun 2024 14:54:22 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v10]
In-Reply-To: <5q2H_Fgz9nY_ykqrqhsfSXv8zQgpfkEOmdUpaAwN3Q0=.d58059e5-d408-4356-824d-413eda97a347@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
 <5q2H_Fgz9nY_ykqrqhsfSXv8zQgpfkEOmdUpaAwN3Q0=.d58059e5-d408-4356-824d-413eda97a347@github.com>
Message-ID: <12KzjRFhvphnxSWCNUA5wqcZgOqD4gKNjGf2rfqZMN8=.77983b3e-10b0-4742-86c3-b940f59d4e46@github.com>

On Fri, 14 Jun 2024 14:00:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1461:
>> 
>>> 1459:                 throw rte;
>>> 1460:             } else {
>>> 1461:                 throw new PrivilegedActionException(e);
>> 
>> The 4 lines above seems unnecessary now. Plus, do not wrap `PrivilegedActionException` inside `PrivilegedActionException`.
>
> It needs to recognise and throw RuntimeException so that a SecurityException isn't wrapped in a PrivilegedActionException (which gets caught by those blocks of code which call extractException(pe) and  look at what Exception it contains).
> 
> (test/jdk/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java tests this)
> 
> I can add a check to make sure PrivilgedActionException doesn't get wrapped.  Daniel I think mentioned this also.

I still don't understand how a SecurityException could be wrapped into a PAE without these lines.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639950681

From kevinw at openjdk.org  Fri Jun 14 15:21:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 15:21:14 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v10]
In-Reply-To: <12KzjRFhvphnxSWCNUA5wqcZgOqD4gKNjGf2rfqZMN8=.77983b3e-10b0-4742-86c3-b940f59d4e46@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
 <5q2H_Fgz9nY_ykqrqhsfSXv8zQgpfkEOmdUpaAwN3Q0=.d58059e5-d408-4356-824d-413eda97a347@github.com>
 <12KzjRFhvphnxSWCNUA5wqcZgOqD4gKNjGf2rfqZMN8=.77983b3e-10b0-4742-86c3-b940f59d4e46@github.com>
Message-ID: <2SJaGWGbzMoPydmzRN5rE_9uEWjNlCY_tFQCU06AcTw=.286f68b1-50ec-4223-b56b-b59f20ebdfc1@github.com>

On Fri, 14 Jun 2024 14:51:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> It needs to recognise and throw RuntimeException so that a SecurityException isn't wrapped in a PrivilegedActionException (which gets caught by those blocks of code which call extractException(pe) and  look at what Exception it contains).
>> 
>> (test/jdk/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java tests this)
>> 
>> I can add a check to make sure PrivilgedActionException doesn't get wrapped.  Daniel I think mentioned this also.
>
> I still don't understand how a SecurityException could be wrapped into a PAE without these lines.

I misunderstood the comment, yes I think I can remove this block now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639983304

From kevinw at openjdk.org  Fri Jun 14 15:26:54 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 15:26:54 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v13]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>

> 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:

  Unnecessary catches to remove

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/d5f68b02..13d9202f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=11-12

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 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

From weijun at openjdk.org  Sun Jun 16 01:57:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 16 Jun 2024 01:57:23 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v13]
In-Reply-To: <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>
Message-ID: <sRb3ETsM2lP1ZBPr7zlspeHqYQMjA07Wb6YbcJhCyLQ=.5534d0b1-08dc-45f0-83a1-8ef097838878@github.com>

On Fri, 14 Jun 2024 15:26:54 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>   Unnecessary catches to remove

src/java.management/share/classes/javax/management/monitor/Monitor.java line 1542:

> 1540:             if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
> 1541:                 // No SecurityManager permitted:
> 1542:                 Subject.doAs(s, action); // s is permitted to be null

While `s` is permitted to be null, calling `Subject.doAs(null, action)` actually sets the current subject to null while calling `action`. This is not same as directly calling `action` where the current subject (could be non null) is used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1641593366

From kevinw at openjdk.org  Mon Jun 17 09:36:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 09:36:33 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v14]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <IbwKY7mW_FmbcAV0MjN5n2WYramr_kbyeui7ouypVJw=.e3e04af8-b6e5-47ca-9961-839a5252d4c9@github.com>

> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8333344_JMX_Subject
 - Monitor: do not call doAs with an explicityly null Subject
 - Unnecessary catches to remove
 - Monitor update
 - ServerNotifForwarder simplification
 - Separate SM allowed and not allowed cases
 - ServerNotifForwarder getSubject update
 - Exception handling per Daniel comment
 - Annotation in checkAccess
 -  Undo test policy updates
 - ... and 9 more: https://git.openjdk.org/jdk/compare/c0b2e87b...ee2dd12e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/13d9202f..ee2dd12e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=12-13

  Stats: 15038 lines in 603 files changed: 6231 ins; 7274 del; 1533 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

From kevinw at openjdk.org  Mon Jun 17 09:36:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 09:36:33 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v13]
In-Reply-To: <sRb3ETsM2lP1ZBPr7zlspeHqYQMjA07Wb6YbcJhCyLQ=.5534d0b1-08dc-45f0-83a1-8ef097838878@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>
 <sRb3ETsM2lP1ZBPr7zlspeHqYQMjA07Wb6YbcJhCyLQ=.5534d0b1-08dc-45f0-83a1-8ef097838878@github.com>
Message-ID: <24tYAB_NAd2xlS1OcTcyqphpFnl17RqS-lCv6avPX04=.fdea8971-3e2b-4ba9-9e14-78e1381823da@github.com>

On Sun, 16 Jun 2024 01:54:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unnecessary catches to remove
>
> src/java.management/share/classes/javax/management/monitor/Monitor.java line 1542:
> 
>> 1540:             if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>> 1541:                 // No SecurityManager permitted:
>> 1542:                 Subject.doAs(s, action); // s is permitted to be null
> 
> While `s` is permitted to be null, calling `Subject.doAs(null, action)` actually sets the current subject to null while calling `action`. This is not same as directly calling `action` where the current subject (could be non null) is used.

Yes, good point, got it. 8-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642504749

From kevinw at openjdk.org  Mon Jun 17 10:03:27 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 10:03:27 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v15]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <049IkM0XAZH--nI3kzEx5sr9bTZEmKAEthTpraZ0vQc=.a8195e52-7c69-458a-abf9-26e91702e8b3@github.com>

> 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 two additional commits since the last revision:

 - leave noPermissionsACC in place for now
 - leave noPermissionsACC in place for now

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/ee2dd12e..2f2179e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=13-14

  Stats: 6 lines in 1 file changed: 4 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

From kevinw at openjdk.org  Mon Jun 17 10:06:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 10:06:14 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v10]
In-Reply-To: <ALogI3wbbzp9cQ-2KJKwXjcPLsWa5wkqUdX8N5qgCyc=.ff71b0c6-ba82-4231-867f-3b88b9497db8@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
 <cp-kNjl5sDRtOtdqgru1Vvs7zS3cQ4yq1lAnzQlrBXw=.e09c9e03-46b5-4fca-856d-cc064f09e495@github.com>
 <ALogI3wbbzp9cQ-2KJKwXjcPLsWa5wkqUdX8N5qgCyc=.ff71b0c6-ba82-4231-867f-3b88b9497db8@github.com>
Message-ID: <Fkj4mnp6LY4WRxS3JwZesaLFb0qM8Qk5qHSJPygP34s=.7d6af1c9-9135-43aa-ba8b-41af3df8661e@github.com>

On Fri, 14 Jun 2024 14:48:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > Does noPermissionsACC add anything?
> 
> I don't know. My principal for this code change is that nothing is changed for the SM-is-allowed case.

I've put back the noPermissionsACC for this change, it does not have to be removed in this change.  It was introduced in jdk6, and we will remove it next time we are here when we drop ACC usage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2172948152

From weijun at openjdk.org  Mon Jun 17 12:41:15 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 17 Jun 2024 12:41:15 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v15]
In-Reply-To: <049IkM0XAZH--nI3kzEx5sr9bTZEmKAEthTpraZ0vQc=.a8195e52-7c69-458a-abf9-26e91702e8b3@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <049IkM0XAZH--nI3kzEx5sr9bTZEmKAEthTpraZ0vQc=.a8195e52-7c69-458a-abf9-26e91702e8b3@github.com>
Message-ID: <5qJoLdiqlmc02xfIUc-MSU4nr5LKzHI-ZLXhqoSZOIc=.851faac0-72bc-4ec6-bf66-2740231aad2e@github.com>

On Mon, 17 Jun 2024 10:03:27 GMT, Kevin Walls <kevinw at openjdk.org> 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 two additional commits since the last revision:
> 
>  - leave noPermissionsACC in place for now
>  - leave noPermissionsACC in place for now

Looks good to me. Just 2 tiny coding style issues.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1436:

> 1434:                         return op.run();
> 1435:                     } catch (Exception e) {
> 1436:                         if (e instanceof RuntimeException)

Enclose the next line in braces.

src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:

> 347:     @SuppressWarnings("removal")
> 348:     private Subject getSubject() {
> 349:        return Subject.current();

Add a leading whitespace.

-------------

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19624#pullrequestreview-2122787201
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642742989
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642743676

From kevinw at openjdk.org  Mon Jun 17 12:41:15 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 12:41:15 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v15]
In-Reply-To: <5qJoLdiqlmc02xfIUc-MSU4nr5LKzHI-ZLXhqoSZOIc=.851faac0-72bc-4ec6-bf66-2740231aad2e@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <049IkM0XAZH--nI3kzEx5sr9bTZEmKAEthTpraZ0vQc=.a8195e52-7c69-458a-abf9-26e91702e8b3@github.com>
 <5qJoLdiqlmc02xfIUc-MSU4nr5LKzHI-ZLXhqoSZOIc=.851faac0-72bc-4ec6-bf66-2740231aad2e@github.com>
Message-ID: <KR6r7-9EAauXGoWWFrHo9PfpXoskKHuiuh76plEPffM=.d18a8e8c-acee-4d4a-892f-cdef77609fea@github.com>

On Mon, 17 Jun 2024 12:33:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - leave noPermissionsACC in place for now
>>  - leave noPermissionsACC in place for now
>
> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
> 
>> 347:     @SuppressWarnings("removal")
>> 348:     private Subject getSubject() {
>> 349:        return Subject.current();
> 
> Add a leading whitespace.

got it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642749038

From kevinw at openjdk.org  Mon Jun 17 12:54:44 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 12:54:44 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v16]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>

> 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 two additional commits since the last revision:

 - style update
 - whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/2f2179e7..597264b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=14-15

  Stats: 11 lines in 2 files changed: 4 ins; 0 del; 7 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

From kevinw at openjdk.org  Mon Jun 17 12:54:44 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 12:54:44 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v15]
In-Reply-To: <5qJoLdiqlmc02xfIUc-MSU4nr5LKzHI-ZLXhqoSZOIc=.851faac0-72bc-4ec6-bf66-2740231aad2e@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <049IkM0XAZH--nI3kzEx5sr9bTZEmKAEthTpraZ0vQc=.a8195e52-7c69-458a-abf9-26e91702e8b3@github.com>
 <5qJoLdiqlmc02xfIUc-MSU4nr5LKzHI-ZLXhqoSZOIc=.851faac0-72bc-4ec6-bf66-2740231aad2e@github.com>
Message-ID: <uLCqOZEpYx1RI2_D-Cfj9AS-uzCGZpR03ZXfjYlCPqA=.d6220bf5-e3b2-48f8-9354-4b3accbd130c@github.com>

On Mon, 17 Jun 2024 12:33:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - leave noPermissionsACC in place for now
>>  - leave noPermissionsACC in place for now
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1436:
> 
>> 1434:                         return op.run();
>> 1435:                     } catch (Exception e) {
>> 1436:                         if (e instanceof RuntimeException)
> 
> Enclose the next line in braces.

Yes this file is full of pre-existing style problems like that.  I can update this and its friend at 1451.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642763028

From dfuchs at openjdk.org  Mon Jun 17 14:12:20 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Jun 2024 14:12:20 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v13]
In-Reply-To: <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>
Message-ID: <2mtwqvJmQWckd_gItk_ZImn-DoSfqLfYqKNn5LfsEZc=.5d214dee-d325-4530-806a-ad6e7e739d5f@github.com>

On Fri, 14 Jun 2024 15:26:54 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>   Unnecessary catches to remove

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1437:

> 1435:                     } catch (Exception e) {
> 1436:                         if (e instanceof RuntimeException)
> 1437:                            throw (RuntimeException) e;

Suggestion:

                        if (e instanceof RuntimeException rte)
                           throw rte;

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1450:

> 1448:                     } catch (Exception e) {
> 1449:                         if (e instanceof RuntimeException)
> 1450:                            throw (RuntimeException) e;

Suggestion:

                        if (e instanceof RuntimeException rte)
                           throw rte;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1640033632
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1640034429

From dfuchs at openjdk.org  Mon Jun 17 14:12:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Jun 2024 14:12:18 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v16]
In-Reply-To: <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
Message-ID: <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>

On Mon, 17 Jun 2024 12:54:44 GMT, Kevin Walls <kevinw at openjdk.org> 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 two additional commits since the last revision:
> 
>  - style update
>  - whitespace

The new version looks much better to me. I wonder if we can abstract away some of the repeated logic though.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1314:

> 1312:                     return AccessController.doPrivileged(action, acc);
> 1313:                 }
> 1314:             }

This piece of code is repeated at several places in similar but different forms - sometime we check for `SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime for `! SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime we check for `acc == null`, sometime for `acc != null` etc.. 
I wonder if we could abstract that to some utility method somewhere. Would that make sense? Maybe that's not possible due to using sometime `PrivelegedAction` and sometimes `PrivilegedExceptionAction` - but maybe we could use `PrivilegedExceptionAction` everywhere at the cost of handling `PrivilegedActionException`? 
If that doesn't prove useful (if handling `PrivilegedExceptionAction` adds again an equivalent amount of clutter) then maybe we could at least make sure we do the same checks in the same way (typically `acc == null` vs `acc != null`)?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19624#pullrequestreview-2118725434
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642864523

From kevinw at openjdk.org  Mon Jun 17 15:59:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 15:59:37 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v17]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>

> 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:

  Remove import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/597264b9..67aca736

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=15-16

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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

From kevinw at openjdk.org  Mon Jun 17 15:59:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 15:59:37 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v16]
In-Reply-To: <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
 <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>
Message-ID: <k2_DFVlnyLAAu_R2I6l8bGeula1PiDaKx8oPYlfn0nA=.1c7d5aa1-ea23-4086-a6f8-374eec84ddaa@github.com>

On Mon, 17 Jun 2024 13:58:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - style update
>>  - whitespace
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1314:
> 
>> 1312:                     return AccessController.doPrivileged(action, acc);
>> 1313:                 }
>> 1314:             }
> 
> This piece of code is repeated at several places in similar but different forms - sometime we check for `SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime for `! SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime we check for `acc == null`, sometime for `acc != null` etc.. 
> I wonder if we could abstract that to some utility method somewhere. Would that make sense? Maybe that's not possible due to using sometime `PrivelegedAction` and sometimes `PrivilegedExceptionAction` - but maybe we could use `PrivilegedExceptionAction` everywhere at the cost of handling `PrivilegedActionException`? 
> If that doesn't prove useful (if handling `PrivilegedExceptionAction` adds again an equivalent amount of clutter) then maybe we could at least make sure we do the same checks in the same way (typically `acc == null` vs `acc != null`)?

Hi,
We almost always check !SharedSecrets.getJavaLangAccess().allowSecurityManager() (except in the RMIConnectionImpl contstructor)

This keeps the "modern" case first (except in that constructor, where it is only one line for each side of the if...).

This extra checking of SharedSecrets.getJavaLangAccess().allowSecurityManager() is to keep the modern and old style cases distinct, based on other comments here.  It keeps it simple to read I hope, but yes it is a little more verbose than it could be.

I'm hoping you'll agree that as these checks will be removed anyway, probably with a release, we should delay more extensive cleanup until then.  (I've also  rolled back my noPermissionsACC removal to keep this change away from being a general cleanup.)

I had a bunch of additional Exception handling for e.g. PrivilegedActionException I think in here, and it wasn't very pretty.  But, it might look better when there are fewer nested ifs in these methods, and when we are properly in the post-SecurityManager world... 8-)

Whether it checks acc != null or acc == null is based on the existing code.  I think that makes this diff easier to read, but also could be reworked and be made more consistent after SM removal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1643036701

From mullan at openjdk.org  Mon Jun 17 19:59:15 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 17 Jun 2024 19:59:15 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v17]
In-Reply-To: <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>
Message-ID: <N6SYKYLB33IV-G1rjfWa4pFzsR-kim0lFCHyh3rM_44=.b5514229-4330-4f14-8ef8-9ea97ae6efbc@github.com>

On Mon, 17 Jun 2024 15:59:37 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>   Remove import

AFAICT, the only test modified in this PR that actually enables a Security Manager is test/jdk/javax/management/security/AuthorizationTest.java. Is that test sufficient to exercise the code changes in this PR when an SM is enabled?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2174313063

From mullan at openjdk.org  Mon Jun 17 20:30:16 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 17 Jun 2024 20:30:16 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v17]
In-Reply-To: <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>
Message-ID: <UwkvEflj9aYgHkIybhTE2-GWkKnmhx95KG8c8MKeuM4=.c57bfacb-40d1-4670-a7e0-2408a00d3525@github.com>

On Mon, 17 Jun 2024 15:59:37 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>   Remove import

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1306:

> 1304:                     return action.run();
> 1305:                 else
> 1306:                     return Subject.doAs(subject, action);

Code style comment: put braces around the if/else to be consistent with lines below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1643390138

From mullan at openjdk.org  Mon Jun 17 20:30:18 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 17 Jun 2024 20:30:18 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v16]
In-Reply-To: <k2_DFVlnyLAAu_R2I6l8bGeula1PiDaKx8oPYlfn0nA=.1c7d5aa1-ea23-4086-a6f8-374eec84ddaa@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
 <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>
 <k2_DFVlnyLAAu_R2I6l8bGeula1PiDaKx8oPYlfn0nA=.1c7d5aa1-ea23-4086-a6f8-374eec84ddaa@github.com>
Message-ID: <bNZqEmj_nYQ55lQvaubYBsEPjCnCHHbi0VdBtexVtb4=.52a73eb6-6d91-46f5-8a8b-623cef3d5530@github.com>

On Mon, 17 Jun 2024 15:53:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1314:
>> 
>>> 1312:                     return AccessController.doPrivileged(action, acc);
>>> 1313:                 }
>>> 1314:             }
>> 
>> This piece of code is repeated at several places in similar but different forms - sometime we check for `SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime for `! SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime we check for `acc == null`, sometime for `acc != null` etc.. 
>> I wonder if we could abstract that to some utility method somewhere. Would that make sense? Maybe that's not possible due to using sometime `PrivelegedAction` and sometimes `PrivilegedExceptionAction` - but maybe we could use `PrivilegedExceptionAction` everywhere at the cost of handling `PrivilegedActionException`? 
>> If that doesn't prove useful (if handling `PrivilegedExceptionAction` adds again an equivalent amount of clutter) then maybe we could at least make sure we do the same checks in the same way (typically `acc == null` vs `acc != null`)?
>
> Hi,
> We almost always check !SharedSecrets.getJavaLangAccess().allowSecurityManager() (except in the RMIConnectionImpl contstructor)
> 
> This keeps the "modern" case first (except in that constructor, where it is only one line for each side of the if...).
> 
> This extra checking of SharedSecrets.getJavaLangAccess().allowSecurityManager() is to keep the modern and old style cases distinct, based on other comments here.  It keeps it simple to read I hope, but yes it is a little more verbose than it could be.
> 
> I'm hoping you'll agree that as these checks will be removed anyway, probably with a release, we should delay more extensive cleanup until then.  (I've also  rolled back my noPermissionsACC removal to keep this change away from being a general cleanup.)
> 
> I had a bunch of additional Exception handling for e.g. PrivilegedActionException I think in here, and it wasn't very pretty.  But, it might look better when there are fewer nested ifs in these methods, and when we are properly in the post-SecurityManager world... 8-)
> 
> Whether it checks acc != null or acc == null is based on the existing code.  I think that makes this diff easier to read, but also could be reworked and be made more consistent after SM removal.

Agree with Kevin. To minimize risk, especially since this is to fix a significant regression and we are in RDP1, we are really trying to preserve the existing code as much as possible, even though it could be improved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1643395182

From kevinw at openjdk.org  Mon Jun 17 20:51:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 20:51:34 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v18]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>

> 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

From weijun at openjdk.org  Mon Jun 17 22:52:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 17 Jun 2024 22:52:12 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v17]
In-Reply-To: <N6SYKYLB33IV-G1rjfWa4pFzsR-kim0lFCHyh3rM_44=.b5514229-4330-4f14-8ef8-9ea97ae6efbc@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>
 <N6SYKYLB33IV-G1rjfWa4pFzsR-kim0lFCHyh3rM_44=.b5514229-4330-4f14-8ef8-9ea97ae6efbc@github.com>
Message-ID: <DuhLCm3oqnYEXcFHOwF1XYXS9zGyxC7rXvd4H_dZSHo=.08b67185-8a5b-41d5-a4a4-1defe579c189@github.com>

On Mon, 17 Jun 2024 19:56:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> AFAICT, the only test modified in this PR that actually enables a Security Manager is test/jdk/javax/management/security/AuthorizationTest.java. Is that test sufficient to exercise the code changes in this PR when an SM is enabled?

While this code change has done its best to avoid any behavior change when SM is allowed, I agree with Sean to run tests in both modes. When these tests were originally introduced they were meant to test the old implementation. Keep testing eith both implementations help us to avoid any future (might not be long) regression.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2174568617

From kevinw at openjdk.org  Tue Jun 18 10:52:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Jun 2024 10:52:13 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v18]
In-Reply-To: <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
Message-ID: <yguKr43BeWYo7Cv84-OpDs7w_Dri2cDApOaDzZUk1Yg=.f17fe80d-62b6-44f8-a68a-2fa9ed2bf34d@github.com>

On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls <kevinw at openjdk.org> 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

From alanb at openjdk.org  Tue Jun 18 11:08:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jun 2024 11:08:11 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v18]
In-Reply-To: <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
Message-ID: <StONdJj3hnPMIhPy8s60aHy_O0hbYRis9SfdPuy92kI=.a83b0472-ed75-4201-95ef-90ec3727ba94@github.com>

On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls <kevinw at openjdk.org> 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

From dfuchs at openjdk.org  Tue Jun 18 11:36:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Jun 2024 11:36:12 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v16]
In-Reply-To: <bNZqEmj_nYQ55lQvaubYBsEPjCnCHHbi0VdBtexVtb4=.52a73eb6-6d91-46f5-8a8b-623cef3d5530@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
 <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>
 <k2_DFVlnyLAAu_R2I6l8bGeula1PiDaKx8oPYlfn0nA=.1c7d5aa1-ea23-4086-a6f8-374eec84ddaa@github.com>
 <bNZqEmj_nYQ55lQvaubYBsEPjCnCHHbi0VdBtexVtb4=.52a73eb6-6d91-46f5-8a8b-623cef3d5530@github.com>
Message-ID: <wL_WtVjqrsFxG0Hw3Mtckp6P46RGEjjw1swBwg0noYk=.5a506c00-9e83-4260-8305-9aaf10723bbf@github.com>

On Mon, 17 Jun 2024 20:27:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hi,
>> We almost always check !SharedSecrets.getJavaLangAccess().allowSecurityManager() (except in the RMIConnectionImpl contstructor)
>> 
>> This keeps the "modern" case first (except in that constructor, where it is only one line for each side of the if...).
>> 
>> This extra checking of SharedSecrets.getJavaLangAccess().allowSecurityManager() is to keep the modern and old style cases distinct, based on other comments here.  It keeps it simple to read I hope, but yes it is a little more verbose than it could be.
>> 
>> I'm hoping you'll agree that as these checks will be removed anyway, probably with a release, we should delay more extensive cleanup until then.  (I've also  rolled back my noPermissionsACC removal to keep this change away from being a general cleanup.)
>> 
>> I had a bunch of additional Exception handling for e.g. PrivilegedActionException I think in here, and it wasn't very pretty.  But, it might look better when there are fewer nested ifs in these methods, and when we are properly in the post-SecurityManager world... 8-)
>> 
>> Whether it checks acc != null or acc == null is based on the existing code.  I think that makes this diff easier to read, but also could be reworked and be made more consistent after SM removal.
>
> Agree with Kevin. To minimize risk, especially since this is to fix a significant regression and we are in RDP1, we are really trying to preserve the existing code as much as possible, even though it could be improved.

It is also more error prone (which is why I suggested using a single well tested utility method to implement the temporary hackery rather than spreading it at different places in different forms). But I'm OK with the code in this form.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1644303322

From kevinw at openjdk.org  Tue Jun 18 12:17:46 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Jun 2024 12:17:46 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v19]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>

> 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:

  Additional test runs with SM enabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/384a3a19..697fc0d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=17-18

  Stats: 7 lines in 3 files changed: 7 ins; 0 del; 0 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

From kevinw at openjdk.org  Tue Jun 18 12:17:46 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Jun 2024 12:17:46 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v18]
In-Reply-To: <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
Message-ID: <ALvHHVyxYdAe54QrghKh5Y0sUv17FTCKzNVfNO9o-Ww=.6a8b71c8-1713-4ee3-b6fe-95255fc635ee@github.com>

On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls <kevinw at openjdk.org> 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

From kevinw at openjdk.org  Tue Jun 18 12:25:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Jun 2024 12:25:18 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v16]
In-Reply-To: <wL_WtVjqrsFxG0Hw3Mtckp6P46RGEjjw1swBwg0noYk=.5a506c00-9e83-4260-8305-9aaf10723bbf@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
 <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>
 <k2_DFVlnyLAAu_R2I6l8bGeula1PiDaKx8oPYlfn0nA=.1c7d5aa1-ea23-4086-a6f8-374eec84ddaa@github.com>
 <bNZqEmj_nYQ55lQvaubYBsEPjCnCHHbi0VdBtexVtb4=.52a73eb6-6d91-46f5-8a8b-623cef3d5530@github.com>
 <wL_WtVjqrsFxG0Hw3Mtckp6P46RGEjjw1swBwg0noYk=.5a506c00-9e83-4260-8305-9aaf10723bbf@github.com>
Message-ID: <qDRAxV6PniMw15KX3rUlFKbruMOZwuUYk4dSnjk55YY=.4a58ed30-e605-4bd2-9f50-f5d53737559a@github.com>

On Tue, 18 Jun 2024 11:33:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Agree with Kevin. To minimize risk, especially since this is to fix a significant regression and we are in RDP1, we are really trying to preserve the existing code as much as possible, even though it could be improved.
>
> It is also more error prone (which is why I suggested using a single well tested utility method to implement the temporary hackery rather than spreading it at different places in different forms). But I'm OK with the code in this form.

Thanks Daniel!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1644374757

From dfuchs at openjdk.org  Wed Jun 19 11:24:16 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 19 Jun 2024 11:24:16 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v19]
In-Reply-To: <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>
Message-ID: <XtBoIoECiDQjmCNTi-7fpxctvLaTnbZz2G2n6RBS_GQ=.9a6e67ba-7c13-4724-8606-dec36377501a@github.com>

On Tue, 18 Jun 2024 12:17:46 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>   Additional test runs with SM enabled

The code changes look good to me (if a bit verbose) and the test changes look reasonable. It could be beneficial to add some more tests in the future involving monitoring and getting the subject from within a monitored MBean.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19624#pullrequestreview-2127943873

From kevinw at openjdk.org  Wed Jun 19 11:33:12 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Jun 2024 11:33:12 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v19]
In-Reply-To: <XtBoIoECiDQjmCNTi-7fpxctvLaTnbZz2G2n6RBS_GQ=.9a6e67ba-7c13-4724-8606-dec36377501a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>
 <XtBoIoECiDQjmCNTi-7fpxctvLaTnbZz2G2n6RBS_GQ=.9a6e67ba-7c13-4724-8606-dec36377501a@github.com>
Message-ID: <AxULD2W738W2iOTPona5XLppy5WY_2v-QmpP-WucsFM=.6dce5000-48a0-4f60-9033-9457801b2146@github.com>

On Wed, 19 Jun 2024 11:21:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The code changes look good to me (if a bit verbose) and the test changes look reasonable. It could be beneficial to add some more tests in the future involving monitoring and getting the subject from within a monitored MBean.

Yes, agreed. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2178461246

From kevinw at openjdk.org  Wed Jun 19 16:38:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Jun 2024 16:38:18 GMT
Subject: jmx-dev RFR: 8333344: JMX attaching of Subject does not work
 when security manager not allowed [v19]
In-Reply-To: <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>
Message-ID: <6DZAICD7aTF44fKtMTT1061FHQYv9d3JpLLqo_uGewU=.8c5d4ea9-218b-480f-bff1-ef050d3cd3ae@github.com>

On Tue, 18 Jun 2024 12:17:46 GMT, Kevin Walls <kevinw at openjdk.org> 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:
> 
>   Additional test runs with SM enabled

Integrating, thanks for all the comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2179099175

From kevinw at openjdk.org  Wed Jun 19 16:38:19 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Jun 2024 16:38:19 GMT
Subject: jmx-dev Integrated: 8333344: JMX attaching of Subject does not work
 when security manager not allowed
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <IxGiF8r8a1ENredV58PPDLB6uBqFcP5AHVi6UKmdRI0=.4b8d874e-1445-44fa-b225-e7e197528e25@github.com>

On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls <kevinw at openjdk.org> 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.

This pull request has now been integrated.

Changeset: bcf4bb48
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f
Stats:     162 lines in 17 files changed: 113 ins; 3 del; 46 mod

8333344: JMX attaching of Subject does not work when security manager not allowed

Reviewed-by: weijun, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Thu Jun 20 20:07:20 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 20 Jun 2024 20:07:20 GMT
Subject: jmx-dev [jdk23] RFR: 8333344: JMX attaching of Subject does not
 work when security manager not allowed
Message-ID: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>

8333344: JMX attaching of Subject does not work when security manager not allowed

-------------

Commit messages:
 - Backport bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f

Changes: https://git.openjdk.org/jdk/pull/19810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333344
  Stats: 162 lines in 17 files changed: 113 ins; 3 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/19810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19810/head:pull/19810

PR: https://git.openjdk.org/jdk/pull/19810

From dfuchs at openjdk.org  Fri Jun 21 09:39:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Jun 2024 09:39:10 GMT
Subject: jmx-dev [jdk23] RFR: 8333344: JMX attaching of Subject does not
 work when security manager not allowed
In-Reply-To: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
References: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
Message-ID: <CPqgovD--dzKQyoJwjoku3og1Ma4z1m8GonV0SSxIDc=.9f616f3a-1013-4ed1-a147-18d82178b84b@github.com>

On Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 8333344: JMX attaching of Subject does not work when security manager not allowed

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19810#pullrequestreview-2132226211

From kevinw at openjdk.org  Fri Jun 21 09:39:11 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 09:39:11 GMT
Subject: jmx-dev [jdk23] RFR: 8333344: JMX attaching of Subject does not
 work when security manager not allowed
In-Reply-To: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
References: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
Message-ID: <WvmoXagyDvZH_hI4oRJCMjOBLHls13YzOZodNWm0szE=.5e045404-6e7b-4964-b038-ab19294f5f27@github.com>

On Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 8333344: JMX attaching of Subject does not work when security manager not allowed

Thanks Daniel.  Testing automated and manual looks good in 24 and in this 23 backport, so I'll get this integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19810#issuecomment-2182392102

From kevinw at openjdk.org  Fri Jun 21 10:12:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 10:12:14 GMT
Subject: jmx-dev [jdk23] Integrated: 8333344: JMX attaching of Subject does
 not work when security manager not allowed
In-Reply-To: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
References: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
Message-ID: <Vsnat6Klsc1cdKNeXujA3H1UtZpbMjya3d41SADlh9s=.2bde1226-6f6a-497f-943e-e354652db574@github.com>

On Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 8333344: JMX attaching of Subject does not work when security manager not allowed

This pull request has now been integrated.

Changeset: 23f2c97f
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23f2c97f4ce42316fd51290175b01b41bcc24f6b
Stats:     162 lines in 17 files changed: 113 ins; 3 del; 46 mod

8333344: JMX attaching of Subject does not work when security manager not allowed

Reviewed-by: dfuchs
Backport-of: bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f

-------------

PR: https://git.openjdk.org/jdk/pull/19810

From kevinw at openjdk.org  Thu Jun 27 09:32:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Jun 2024 09:32:33 GMT
Subject: jmx-dev RFR: 8335124:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU
 time out of expected range
Message-ID: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>

This test has had occasional failures for years, possibly forever.
A previous update made the test "othervm" which removed some interruptions, but a time accounting problem remains.

This change adds a simple sleep after observing that the test threads are all sleeping.

The idea is that threads may not have actually started sleeping when we observe their java.lang.Thread.State as WAITING, they may use some CPU time after that in order to actually get to sleep.

-------------

Commit messages:
 - 8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range

Changes: https://git.openjdk.org/jdk/pull/19924/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19924&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335124
  Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19924.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19924/head:pull/19924

PR: https://git.openjdk.org/jdk/pull/19924

From kevinw at openjdk.org  Thu Jun 27 09:32:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Jun 2024 09:32:33 GMT
Subject: jmx-dev RFR: 8335124:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU
 time out of expected range
In-Reply-To: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>
References: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>
Message-ID: <IDfg5tVt-m0wIvkX8s2KPdAYPO2clMDvHyxalkhI_8c=.b0fed032-cd11-48cc-804f-778ea035a456@github.com>

On Thu, 27 Jun 2024 08:54:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has had occasional failures for years, possibly forever.
> A previous update made the test "othervm" which removed some interruptions, but a time accounting problem remains.
> 
> This change adds a simple sleep after observing that the test threads are all sleeping.
> 
> The idea is that threads may not have actually started sleeping when we observe their java.lang.Thread.State as WAITING, they may use some CPU time after that in order to actually get to sleep.

The test waits for the state of test threads to be WAITING.  There are a few more lines of test code (which might take 20,000 or 50,0000 ns using simple System.nanoTime calls), then we record threadmxbean.getCpuTime() for threads, do a sleep, and check these times again.

Usually they are the same, no more cpu time was used (correct!).  But the times can be some thousands of nanos different and the test fails.

My theory is that sometimes, a test thread has not really started sleeping yet when we read its state as WAITING and record the first time.  The test should sleep for a few hundred millis before taking the first time readings.

Commonly, in the failures the time discrepancy is under 100,000 nanos, with an example I see of nearly 200,000 nanos and the worst I saw was 15625000 nanos, approx 15ms.


When test threads are waiting, they look like this:

"MyThread-6" #38 [16479] prio=5 os_prio=0 cpu=56.05ms elapsed=34.89s tid=0x000014f83806c590 nid=16479 in Object.wait()  [0x000014f8dd343000]
   java.lang.Thread.State: WAITING (on object monitor)
Thread: 0x000014f83806c590  [0x405f] State: _at_safepoint _at_poll_safepoint 0
   JavaThread state: _thread_blocked
        at java.lang.Object.wait0(java.base at 24-internal/Native Method)
        - waiting on <0x00000000ffa66fc0> (a java.lang.Object)
        at java.lang.Object.wait(java.base at 24-internal/Object.java:374)
        at java.lang.Object.wait(java.base at 24-internal/Object.java:348)
        at ThreadCpuTimeArray$MyThread.run(ThreadCpuTimeArray.java:263)
        - locked <0x00000000ffa66fc0> (a java.lang.Object)


This is a harmless test change either way.  If the theory is wrong, we will see the "out of expected range" failure again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19924#issuecomment-2194213706

From kevinw at openjdk.org  Thu Jun 27 15:58:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Jun 2024 15:58:29 GMT
Subject: jmx-dev RFR: 8334777: Test
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 failed with NullPointerException
Message-ID: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com>

Disable running this test with -Xcomp.

The NPE seen in this test is due to a timeout establishing the connection.  ServerCommunicatorAdmin hits its timeout, during an addNotificationListener call on a new connection.

-Xcomp causes this slowdown and the failure is reproducible.  There is no need to test this test with -Xcomp, we should exclude it as we do for various other tests.

-------------

Commit messages:
 - 8334777: Test javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java failed with NullPointerException

Changes: https://git.openjdk.org/jdk/pull/19930/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19930&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334777
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19930/head:pull/19930

PR: https://git.openjdk.org/jdk/pull/19930

From phh at openjdk.org  Thu Jun 27 17:31:54 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 27 Jun 2024 17:31:54 GMT
Subject: jmx-dev RFR: 8335124:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU
 time out of expected range
In-Reply-To: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>
References: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>
Message-ID: <5u_Z7JLaT1q84cEcNL3R4XQo4Uf-nvpD9T-r8GunpZs=.5c1d0ed6-d122-4810-8480-e833fe0f13c4@github.com>

On Thu, 27 Jun 2024 08:54:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has had occasional failures for years, possibly forever.
> A previous update made the test "othervm" which removed some interruptions, but a time accounting problem remains.
> 
> This change adds a simple sleep after observing that the test threads are all sleeping.
> 
> The idea is that threads may not have actually started sleeping when we observe their java.lang.Thread.State as WAITING, they may use some CPU time after that in order to actually get to sleep.

Makes sense.

-------------

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19924#pullrequestreview-2146005577

From kevinw at openjdk.org  Thu Jun 27 21:33:20 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Jun 2024 21:33:20 GMT
Subject: jmx-dev RFR: 8335124:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU
 time out of expected range
In-Reply-To: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>
References: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>
Message-ID: <VsSty4EwOcuEz93Xj4ZkStlUbkivkSLZvbIS4m0e15k=.62c970d8-d669-4a59-8fdf-c84016c0a8c3@github.com>

On Thu, 27 Jun 2024 08:54:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has had occasional failures for years, possibly forever.
> A previous update made the test "othervm" which removed some interruptions, but a time accounting problem remains.
> 
> This change adds a simple sleep after observing that the test threads are all sleeping.
> 
> The idea is that threads may not have actually started sleeping when we observe their java.lang.Thread.State as WAITING, they may use some CPU time after that in order to actually get to sleep.

Thanks Paul (and may it live for another 13 years!)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19924#issuecomment-2195696432

From cjplummer at openjdk.org  Fri Jun 28 17:58:18 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Jun 2024 17:58:18 GMT
Subject: jmx-dev RFR: 8334777: Test
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 failed with NullPointerException
In-Reply-To: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com>
References: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com>
Message-ID: <JeQwOt0snu5VJDah0VwPpw-pA3t6nIKXlPGFmIOsvCM=.6b5542f6-c225-4318-bcc6-88b52a34a6c3@github.com>

On Thu, 27 Jun 2024 15:53:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Disable running this test with -Xcomp.
> 
> The NPE seen in this test is due to a timeout establishing the connection.  ServerCommunicatorAdmin hits its timeout, during an addNotificationListener call on a new connection.
> 
> -Xcomp causes this slowdown and the failure is reproducible.  There is no need to test this test with -Xcomp, we should exclude it as we do for various other tests.

My main concern is that for the reader of this test it's not obvious why it can't be run with -Xcomp. Maybe add an @comment explaining why.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19930#pullrequestreview-2148647550

From kevinw at openjdk.org  Fri Jun 28 18:14:59 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 28 Jun 2024 18:14:59 GMT
Subject: jmx-dev RFR: 8334777: Test
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 failed with NullPointerException [v2]
In-Reply-To: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com>
References: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com>
Message-ID: <9FY2VW_Ny11qLW-J2zNcCVxJegPctIFXsWd7Q4VACQ4=.49014b43-0ff1-4bf4-a505-5633934c86b0@github.com>

> Disable running this test with -Xcomp.
> 
> The NPE seen in this test is due to a timeout establishing the connection.  ServerCommunicatorAdmin hits its timeout, during an addNotificationListener call on a new connection.
> 
> -Xcomp causes this slowdown and the failure is reproducible.  There is no need to test this test with -Xcomp, we should exclude it as we do for various other tests.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19930/files
  - new: https://git.openjdk.org/jdk/pull/19930/files/3e26ac64..6d83258d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19930&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19930&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19930/head:pull/19930

PR: https://git.openjdk.org/jdk/pull/19930

From cjplummer at openjdk.org  Fri Jun 28 18:21:19 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Jun 2024 18:21:19 GMT
Subject: jmx-dev RFR: 8335124:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU
 time out of expected range
In-Reply-To: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>
References: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>
Message-ID: <Cgn0F_SSHOWbTDjSRqKlfPPsyEbWYeAVKw8s7a8Jfbc=.b4b3dfa1-8363-4c03-adb5-1930e454dc06@github.com>

On Thu, 27 Jun 2024 08:54:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has had occasional failures for years, possibly forever.
> A previous update made the test "othervm" which removed some interruptions, but a time accounting problem remains.
> 
> This change adds a simple sleep after observing that the test threads are all sleeping.
> 
> The idea is that threads may not have actually started sleeping when we observe their java.lang.Thread.State as WAITING, they may use some CPU time after that in order to actually get to sleep.

Looks good, and thank you for giving me a clue as to why [JDK-8269881](https://bugs.openjdk.org/browse/JDK-8269881) has probably been causing test failures for 4 years now. :)

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19924#pullrequestreview-2148687640

From kevinw at openjdk.org  Fri Jun 28 18:23:19 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 28 Jun 2024 18:23:19 GMT
Subject: jmx-dev RFR: 8334777: Test
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 failed with NullPointerException [v2]
In-Reply-To: <9FY2VW_Ny11qLW-J2zNcCVxJegPctIFXsWd7Q4VACQ4=.49014b43-0ff1-4bf4-a505-5633934c86b0@github.com>
References: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com>
 <9FY2VW_Ny11qLW-J2zNcCVxJegPctIFXsWd7Q4VACQ4=.49014b43-0ff1-4bf4-a505-5633934c86b0@github.com>
Message-ID: <DkxE1_Gfl9AcqfAjRNS_LFpY5bX3M3Dwmn3Qu-syx6o=.7b6d9aac-f8b6-4ade-95bd-7777f1d54ae9@github.com>

On Fri, 28 Jun 2024 18:14:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Disable running this test with -Xcomp.
>> 
>> The NPE seen in this test is due to a timeout establishing the connection.  ServerCommunicatorAdmin hits its timeout, during an addNotificationListener call on a new connection.
>> 
>> -Xcomp causes this slowdown and the failure is reproducible.  There is no need to test this test with -Xcomp, we should exclude it as we do for various other tests.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment

Yes sure, I've added a short comment, so it's clear this is intentional and we know -Xcomp causes a specific timeout.  Checked test still runs OK, and skips with -Xcomp.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19930#issuecomment-2197426365

From cjplummer at openjdk.org  Fri Jun 28 18:29:18 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Jun 2024 18:29:18 GMT
Subject: jmx-dev RFR: 8334777: Test
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 failed with NullPointerException [v2]
In-Reply-To: <9FY2VW_Ny11qLW-J2zNcCVxJegPctIFXsWd7Q4VACQ4=.49014b43-0ff1-4bf4-a505-5633934c86b0@github.com>
References: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com>
 <9FY2VW_Ny11qLW-J2zNcCVxJegPctIFXsWd7Q4VACQ4=.49014b43-0ff1-4bf4-a505-5633934c86b0@github.com>
Message-ID: <7O1vE591RZxOlXufUlUJ5K2OuD8_kDZHcMRhPwgn6w8=.026c234b-5415-4a1b-b99e-b580056454fc@github.com>

On Fri, 28 Jun 2024 18:14:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Disable running this test with -Xcomp.
>> 
>> The NPE seen in this test is due to a timeout establishing the connection.  ServerCommunicatorAdmin hits its timeout, during an addNotificationListener call on a new connection.
>> 
>> -Xcomp causes this slowdown and the failure is reproducible.  There is no need to test this test with -Xcomp, we should exclude it as we do for various other tests.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19930#pullrequestreview-2148699020

From kevinw at openjdk.org  Fri Jun 28 19:04:22 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 28 Jun 2024 19:04:22 GMT
Subject: jmx-dev Integrated: 8335124:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU
 time out of expected range
In-Reply-To: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>
References: <Q2eLLdRMDIcfveC7ZlCVZ500V0MnKXPioGFgTx-k3ak=.5e5c6af1-a587-4106-92da-25fd1702f42b@github.com>
Message-ID: <MRkXxp49gO58Q2iCUArQMhA83OY8CwIqIfq90IlMbrg=.50b2e875-9c16-4f92-a1c3-8a26099e527c@github.com>

On Thu, 27 Jun 2024 08:54:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has had occasional failures for years, possibly forever.
> A previous update made the test "othervm" which removed some interruptions, but a time accounting problem remains.
> 
> This change adds a simple sleep after observing that the test threads are all sleeping.
> 
> The idea is that threads may not have actually started sleeping when we observe their java.lang.Thread.State as WAITING, they may use some CPU time after that in order to actually get to sleep.

This pull request has now been integrated.

Changeset: 79a3554e
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79a3554e1da604627b3a010dc269c1bd914c79d3
Stats:     3 lines in 1 file changed: 2 ins; 1 del; 0 mod

8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range

Reviewed-by: phh, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/19924