[ https://issues.apache.org/jira/browse/SOLR-13991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986529#comment-16986529 ]
Ishan Chattopadhyaya commented on SOLR-13991: --------------------------------------------- I ran: {code} ant -Dtests.dups=10 -Dtests.iters=10 -Dbeast.iters=10 beast -Dtestcase=HdfsThreadLeakTest -Dargs="-Djava.security.debug=access,failure" {code} This beast passed fine. Just that there were some .err files, e.g. https://paste.centos.org/view/8a298dca {code} [beaster] Beast round 1 results: /home/ishan/code/lucene-solr/solr/build/solr-core/test/1 [junit4] JVM J0: stderr was not empty, see: /home/ishan/code/lucene-solr/solr/build/solr-core/test/temp/junit4-J0-20191203_074200_02415939473214337899824.syserr [junit4] JVM J2: stderr was not empty, see: /home/ishan/code/lucene-solr/solr/build/solr-core/test/temp/junit4-J2-20191203_074200_02517859560452481003280.syserr [junit4] JVM J3: stderr was not empty, see: /home/ishan/code/lucene-solr/solr/build/solr-core/test/temp/junit4-J3-20191203_074200_0259998800732521280011.syserr [junit4] JVM J1: stderr was not empty, see: /home/ishan/code/lucene-solr/solr/build/solr-core/test/temp/junit4-J1-20191203_074200_0251345432925271321443.syserr [beaster] Beast round 2 results: /home/ishan/code/lucene-solr/solr/build/solr-core/test/2 [junit4] JVM J3: stderr was not empty, see: /home/ishan/code/lucene-solr/solr/build/solr-core/test/temp/junit4-J3-20191203_074238_68315578597558260604512.syserr [junit4] JVM J2: stderr was not empty, see: /home/ishan/code/lucene-solr/solr/build/solr-core/test/temp/junit4-J2-20191203_074238_6822571445674138258678.syserr [junit4] JVM J1: stderr was not empty, see: /home/ishan/code/lucene-solr/solr/build/solr-core/test/temp/junit4-J1-20191203_074238_68282146964914171366.syserr [junit4] JVM J0: stderr was not empty, see: /home/ishan/code/lucene-solr/solr/build/solr-core/test/temp/junit4-J0-20191203_074238_68214871322713580627440.syserr {code} > clean up permissions in solr-tests.policy > ----------------------------------------- > > Key: SOLR-13991 > URL: https://issues.apache.org/jira/browse/SOLR-13991 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Robert Muir > Priority: Major > Attachments: SOLR-13991.patch, SOLR-13991.patch, SOLR-13991.patch, > SOLR-13991.patch > > > The solr-tests.policy is currently way too lenient. Its useful for tests but > pretty worthless at defending against any attacker "for real" > For example imagine i can execute arbitrary java-ish code: > {code} > Runtime.getRuntime().exec("id"); > {code} > With a security manager enabled, I'd get an exception like this: > java.security.AccessControlException: access denied ("java.io.FilePermission" > "<<ALL FILES>>" "execute") > Because the current policy is so lenient and has wildcard RuntimePermission, > the next thing i'd try (disable security manager, then launch process) would > happily execute: > {code} > System.setSecurityManager(null);Runtime.getRuntime().exec("id"); > {code} > That's because the current wildcard permission allows > {{RuntimePermission("setSecurityManager")}}. > There are other variants I could use, some explained by java's docs: > https://docs.oracle.com/javase/7/docs/api/java/lang/RuntimePermission.html > It will take time and pain to clean up this stuff: e.g. fixing code and maybe > even third-party dependencies, but gotta start somewhere. I think splitting > up the wildcards is a good first step :) -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org