RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs [v2]

[Weijun Wang]

On Fri, 22 Oct 2021 21:53:30 GMT, Bernd <duke at openjdk.java.net> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renames
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 475:
> 
>> 473:      *       call {@link #callAs} to perform the same work, which is based on
>> 474:      *       {@link #doAs(Subject, PrivilegedExceptionAction)}
>> 475:      *       by default in this implementation.
> 
> Should it also mention that unless you define the TL system property it will still affect the new current() call? (Just to introduce the concept by repetition).

I just don't want to touch existing spec. Even for `doAs`, I only said "callAs is based on doAs by default" and didn't went out explaining what is NOT by default. Is that OK?

> src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 708:
> 
>> 706:                             @SuppressWarnings("removal")
>> 707:                             final Subject subject =
>> 708:                                 AccessController.doPrivilegedWithCombiner(
> 
> Is this actually needed and correct to wrap this into a priveledged action?

Oh, it's needed. Otherwise the `AccessController.getContext()` call (which is inside `current()`) will also be called in a clean privileged context and there is no subject associated with it.

On the other hand, it still needs to in some sort of doPriv. I don't want to ignore `AuthPermission("getSubject")`.

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

PR: https://git.openjdk.java.net/jdk/pull/5024