Tolerate creation of InnocuousThreads - to facilitate use of java.lang.ref.Cleaner #77788
Labels
Comments
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
pgomulka
added a commit
that referenced
this issue
Nov 23, 2022
…g.ref.Cleaner backport(#77788) (#91852) Update the ES security manager to tolerate the creation of the JDK's InnocuousThreads, to facilitate the use of java.lang.ref.Cleaner in ES and dependent code by default. Further details in issue ( #77788 ) resolves #77788 backport note - in 7.17 branch jdk8 is still supported. Therefore in order to recognize jdk.base domain it has to check for classloader == null (meaning it is a bootstrap classloader) instead of comparing modules backport(#77788)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
During the course of a separate PR [1], it was observed that
java.lang.ref.Cleaner::createchecks that the caller is allowed to create or start a thread - throws SecurityException if not. This is as designed and specified in the Java SE specification. The aforementioned PR [1] runs afoul of this, since it would appear to be the first time that Cleaner is being used in the code base or a transitive dependency.By default, and with a security manager installed, the JDK implementation will create a new InnocuousThread to execute the clean actions of a Cleaner. With the phased migration away from finalizers, it is likely that more libraries will start to adopt j.l.ref.Cleaner. The ES security manager should tolerate its use without the need for each and every codebase to be granted an explicit permission.
When this issue is resolved, the aforementioned PR [1] can remove its changes that relate to dealing with the security manager aspects of granting and checking modifyInnocuousThread.
[1] relates #77012
The text was updated successfully, but these errors were encountered: