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

Bernd duke at openjdk.java.net
Mon Oct 25 19:58:11 UTC 2021

On Mon, 25 Oct 2021 17:58:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/security/auth/Subject.java line 325:
>>> 323: 
>>> 324:     // Store the current subject to a ThreadLocal when a system property is set.
>>> 325:     private static final boolean USE_TL = "true".equalsIgnoreCase(
>> Can you use GetBooleanAction.privilegedGetProperty instead?
> Sure, I can. I was testing the default value to "false" at some time and found `"true".equals` and `!"false".equals` symmetric and good-looking. :-)

It probably doesn’t matter to have the Logic centralized, just looked a bit hardcoded (who knows if yes/no/1/0 is wanted as well ,).

>> src/java.base/share/classes/javax/security/auth/Subject.java line 349:
>>> 347:      * the one of its parent thread, and will not change even if
>>> 348:      * its parent thread's current subject is changed to another value.
>>> 349:      *
>> Should it say something about installing or unsettling the subject in a nested execution (if it can be restricted)?
> I said "After {@code action} is finished, the current subject is reset to its previous value". Is that what you meant?

My question was more along the line of Post-Security-manager. Will you always be able to call Subject.doAs - especially with null? And if this can already be speced if it might be rejected or not… (the „after finished“ is well documented)

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

Yes good reason not to change it.


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

More information about the security-dev mailing list