HI Reto, Thanks for the information. If the 'getClassLoader' permission is not included in the default I will change the engine to load the Solr Attribute in a doPrivileged(..) block. The class name is anyway statically in the code (and not parsed via a configuration). So there is no danger that a user can load remote code.
best Rupert On Thu, Oct 17, 2013 at 11:37 AM, Reto Bachmann-Gmür <r...@apache.org> wrote: > Hi Rupert, Andreas, all > > It seems that indeed ("java.lang.RuntimePermission" "getClassLoader") is not > part of the basePermissionRole in the 0.X branch but is part of this role in > the 1.0 branch. The reason is that the ng branch is using > org.apache.clerezza.platform.config:0.4.0.SNAPSHOT. > > The more fundamental issue is that the default system graph is just provided > by one bundle which sets the system graph if this isn't there yet. Bundles > could of course modify the system graph in ntheir activators but there > should be a mechanism that ensures a bundle makes its modifications only > once and doesn't overwrite subsequent user made changes. > > Cheers, > Reto > > > > > > > On Thu, Oct 17, 2013 at 6:31 AM, Rupert Westenthaler > <rupert.westentha...@gmail.com> wrote: >> >> Hi Andreas, Reto, all >> >> at least we are making progress ... >> ... loading the FST corpus does now work. >> >> But now the engine is running into an other security related problem >> >> java.security.AccessControlException: access denied >> ("java.lang.RuntimePermission" "getClassLoader") >> at >> java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) >> at >> java.security.AccessController.checkPermission(AccessController.java:559) >> at >> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) >> at >> java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1549) >> at java.lang.Class.getClassLoader(Class.java:614) >> at >> org.apache.lucene.util.AttributeSource$AttributeFactory$DefaultAttributeFactory.getClassForInterface(AttributeSource.java:79) >> at >> org.apache.lucene.util.AttributeSource$AttributeFactory$DefaultAttributeFactory.createAttributeInstance(AttributeSource.java:65) >> at >> org.apache.lucene.util.AttributeSource.addAttribute(AttributeSource.java:271) >> at >> org.apache.stanbol.enhancer.engines.lucenefstlinking.LinkableTokenFilter.<init>(LinkableTokenFilter.java:148) >> at >> org.apache.stanbol.enhancer.engines.lucenefstlinking.FstLinkingEngine.tag(FstLinkingEngine.java:358) >> at >> org.apache.stanbol.enhancer.engines.lucenefstlinking.FstLinkingEngine.computeEnhancements(FstLinkingEngine.java:175) >> >> indicating that the SecurityManager denies Solr access to the Classloader. >> >> LinkableTokenFilter.java:148 registers an Solr Analyzer Attribute to >> the TokenFilter. The Attribute in question is provided by a JAR that >> is embedded in the same bundle. Solr uses "Class.forName(..)" in >> AttributeSource.java:79. >> >> @Reto: it it expected that the SecurityManager denies access to the >> Classloader used by Class.forName(..). Should I move the >> initialization of the Attributes in a doPrivileged(..) block, or is >> something really wrong with the SecurityManager configuration of >> Andreas JVM? >> >> best >> Rupert >> >> On Wed, Oct 16, 2013 at 3:31 PM, Andreas Kuckartz <a.kucka...@ping.de> >> wrote: >> > Hi Rupert, >> > >> > thanks again, but unfortunately the integration tests still fail. Log >> > file is appended. >> > >> > Cheers, >> > Andreas >> > --- >> > >> > Rupert Westenthaler: >> >> Hi Andreas >> >> >> >> Based on the new error log the problem was accessing the last >> >> modification date of the FST corpus file outside the doPrivileged() >> >> block. >> >> I have fixed this with http://svn.apache.org/r1532742. >> >> >> >> Would be nice if you could check again >> >> >> >> best >> >> Rupert >> > >> >> >> >> -- >> | Rupert Westenthaler rupert.westentha...@gmail.com >> | Bodenlehenstraße 11 ++43-699-11108907 >> | A-5500 Bischofshofen > > -- | Rupert Westenthaler rupert.westentha...@gmail.com | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen