RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

[Weijun Wang]

On Tue, 5 Mar 2024 16:49:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.
>
> Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
> 
> (That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
> https://github.com/openjdk/jdk/pull/18025 )
> 
> makeClient in RMIJRMPServerImpl creates RMIConnectionImpl
> 
> ..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.

I see that in `RMIConnectionImpl.java` it is stored inside an `AccessControlContext`, and there are `doPrivileged` calls on this ACC to pass the subject into an action. So, even if there might be no SM but the subject will never be bound to a thread using a scoped value.

I’ll revert the change then, and this code must have SM allowed to run correctly. If user runs it with SM disabled, at least they will see an UOE instead of letting `current()` silently returns a null.

Ultimately, if we want it working after SM, we should update `RMIConnectionImpl` and rewrite the ACC-related code to using `Subject.callAs`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1513410552