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

[Bernd]

On Mon, 25 Oct 2021 18:08:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> 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")`.

Hm yes i see why „withacombiner“ would be needed, just not sure why doPriveledged() is needed (especially since current() does it as well). But I admit i don’t see through that part, so ignore me if I don’t make sense.

>> test/jdk/javax/security/auth/Subject/DoAs.java line 44:
>> 
>>> 42:             final int index = i;
>>> 43:             Subject.callAs(subject, () -> {
>>> 44:                 Subject s = Subject.current();
>> 
>> Should it Test old and new method to retrieve subject?
>
> I did it in `CurrentSubject.java` when test=both (checking `cas != accs` in `check()`). All changes to existing tests are just to avoid calling deprecated methods.

Yes, probably not worth it in all tests (but would be maybe a good one time exercise?)

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

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