[ https://issues.apache.org/jira/browse/LUCENE-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448527#comment-13448527 ]
Uwe Schindler edited comment on LUCENE-4332 at 9/5/12 5:58 PM: --------------------------------------------------------------- {code} permission java.security.SecurityPermission "*", "read,write"; {code} This makes no sense, as SecurityPermission has no "action", so "read,write" should be ignored. I was restricting SecurityPermission with something in mind (see the last 2 lines that allowed only the BouncyCastle installed by TIKA - now everything is allowed). What fails if I remove that line? I have no time to run the whole pitest suite.... bq. rather than as a full force prevention of malicious code The idea was to find places (especially in TIKA) that do things they should not do (like enabling security providers), which makes the configuration of J2EE container hosting Solr hard. So we should limit all this, to see when somebody adds a "new feature" to Solr that needs additional permissions. I am already working on restricting "RuntimePermission" more, so only things like "reflection" and "property access" is allowed. was (Author: thetaphi): {code} permission java.security.SecurityPermission "*", "read,write"; {code} This makes no sense, as SecurityPermission has no "action", so "read,write" should be ignored. I was restricting SecurityPermission with something in mind (see the last 2 lines that allowed only the BouncyCastle installed by TIKA - now everything is allowed). What fails if I remove that line? I have no time to run the whole pitest suite.... bq. rather than as a full force prevention of malicious code The idea was to find places (especially in TIKA) that do things they should not do (like enabling security providers), which makes the configuration of J2EE container hosting Solr hard. So we should limit all this, to see when somebody adds a "new feature" to Solr that needs additional permissions. I already working on restricting "RuntimePermission" at all, so only things like "reflection" and "property access" is allowed. > Integrate PiTest mutation coverage tool into build > -------------------------------------------------- > > Key: LUCENE-4332 > URL: https://issues.apache.org/jira/browse/LUCENE-4332 > Project: Lucene - Core > Issue Type: Improvement > Affects Versions: 4.1, 5.0 > Reporter: Greg Bowyer > Assignee: Greg Bowyer > Labels: build > Attachments: > LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch, > LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch, > LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch, > LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch > > > As discussed briefly on the mailing list, this patch is an attempt to > integrate the PiTest mutation coverage tool into the lucene build -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org