RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java
Daniel Fuchs
dfuchs at openjdk.java.net
Wed Jun 2 18:22:29 UTC 2021
On Sat, 22 May 2021 00:20:11 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:
> The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager.
>
> The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used.
>
> I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green.
src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 107:
> 105: List<StackFrame> stack = StackWalker.getInstance(
> 106: StackWalker.Option.RETAIN_CLASS_REFERENCE)
> 107: .walk((s) -> s.collect(Collectors.toList()));
StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE) will require a permission check.
As long as the SecurityManager is still functional, doesn't this mean that creating the StackWalker should be performed in a doPrivileged? If so maybe it should be done in a (possibly static) initializer. Or is it intentional to check that the caller (and the whole calling stack) posses the `RuntimePermission("getStackWalkerWithClassReference")`?
-------------
PR: https://git.openjdk.java.net/jdk/pull/4150
More information about the security-dev
mailing list