On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <[email protected]> wrote:
> This code change adds an alternative implementation of user-based
> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
> Depending on if the Security Manager is allowed, the methods store the
> current subject differently. See the spec change in the `Subject.java` file
> for details. When the Security Manager APIs are finally removed in a future
> release, this new implementation will be only implementation for these
> methods.
>
> One major change in the new implementation is that `Subject.getSubject`
> always throws an `UnsupportedOperationException` since it has an
> `AccessControlContext` argument but the current subject is no longer
> associated with an `AccessControlContext` object.
>
> Now it's the time to migrate from the `getSubject` and `doAs` methods to
> `current` and `callAs`. If the user application is simply calling
> `getSubject(AccessController.getContext())`, then switching to `current()`
> would work. If the `AccessControlContext` argument is retrieved from an
> earlier `getContext()` call and the associated subject might be different
> from that of the current `AccessControlContext`, then instead of storing the
> previous `AccessControlContext` object and passing it into `getSubject` to
> get the "previous" subject, the application should store the `current()`
> return value directly.
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();
Since `Subject::current` is not deprecated the annotation at line 347 above
should be removed.
src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java
line 307:
> 305: AccessController.doPrivileged(new PrivilegedAction<>() {
> 306: public Subject run() {
> 307: return Subject.current();
Is the `doPrivileged` still needed here? Is there a chance that
`Subject.current()` will throw a `SecurityException`, or return a different
result if a security manager is present and `doPrivileged` is not used?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471257982
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471263581
