[jboss-jira] [JBoss JIRA] (DROOLS-2278) Parallel rules compiling does not take into account JVM container security policy
Mario Fusco (Jira)
issues at jboss.org
Wed Mar 11 04:23:46 EDT 2020
[ https://issues.redhat.com/browse/DROOLS-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mario Fusco resolved DROOLS-2278.
---------------------------------
Resolution: Done
Fixed by https://github.com/kiegroup/drools/commit/3331bb5ff2077672deb50115be915ef8a01485ee
> Parallel rules compiling does not take into account JVM container security policy
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-2278
> URL: https://issues.redhat.com/browse/DROOLS-2278
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.5.0.Final
> Environment: Linux 2.6.32-696.13.2.el6.x86_64
> OpenJDK Runtime Environment (build 1.8.0_151-b12)
> OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
> Reporter: Dorin Opris
> Assignee: Mario Fusco
> Priority: Major
>
> We deployed Drools 7.5.0.Final libraries in a java container (commercial product) which specifies a security manager and a policy.
> When running the container with small Drools packages (i.e. number of rules is less than 10) processing goes very well. When it comes to more rules the following exception is issued:
> SEVERE Failed to instantiate <container_unit>; Caused by: org.jini.rio.core.JSBInstantiationException:
> java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "createClassLoader")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
> at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:274)
> at java.lang.ClassLoader.<init>(ClassLoader.java:316)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.<init>(JavaDialectRuntimeData.java:573)
> at org.drools.core.rule.JavaDialectRuntimeData.makeClassLoader(JavaDialectRuntimeData.java:555)
> at org.drools.core.rule.JavaDialectRuntimeData.onAdd(JavaDialectRuntimeData.java:238)
> at org.drools.compiler.rule.builder.dialect.java.JavaDialect.<init>(JavaDialect.java:189)
> at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.newDialect(JavaDialectConfiguration.java:88)
> at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.buildDialectRegistry(KnowledgeBuilderConfigurationImpl.java:377)
> at org.drools.compiler.compiler.PackageRegistry.<init>(PackageRegistry.java:51)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.createPackageRegistry(.java:1051)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$getOrCreatePackageRegistry$0(KnowledgeBuilderImpl.java:1026)
> at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getOrCreatePackageRegistry(KnowledgeBuilderImpl.java:1026)
> at org.drools.compiler.builder.impl.TypeDeclarationCache.createTypeDeclarationForBean(TypeDeclarationCache.java:262)
> at org.drools.compiler.builder.impl.TypeDeclarationCache.getAndRegisterTypeDeclaration(TypeDeclarationCache.java:90)
> at org.drools.compiler.builder.impl.TypeDeclarationBuilder.getAndRegisterTypeDeclaration(TypeDeclarationBuilder.java:69)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getAndRegisterTypeDeclaration(KnowledgeBuilderImpl.java:1781)
> at org.drools.compiler.rule.builder.PatternBuilder.processClassObjectType(PatternBuilder.java:306)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:181)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:151)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:133)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:105)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1202)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$compileRulesLevel$3(KnowledgeBuilderImpl.java:1163)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1380)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
> at java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
> It seems Drools 7.* version has introduced parallel compilation of rules using Java platform forkJoin threads that, according to its spec, are a bit security restrictive in the sense that container security policy or container class loader access control context is ignored.
> "If a SecurityManager is present and no factory is specified, then the default pool uses a factory supplying threads that have no Permissions enabled. The system class loader is used to load these classes." https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html
> Could Drools fix this serial-parallel asymmetric output of rules compilation logic? Or it's just a Java issue like https://bugs.java.com/view_bug.do?bug_id=8184335 ?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
More information about the jboss-jira
mailing list