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

Reply via email to