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