On 5/22/19 3:33 PM, Arthur Eubanks wrote:
On Wed, May 22, 2019 at 12:12 PM Sean Mullan <sean.mul...@oracle.com <mailto:sean.mul...@oracle.com>> wrote:On 5/22/19 1:28 PM, Arthur Eubanks wrote: > On Wed, May 22, 2019 at 7:13 AM Daniel Fuchs <daniel.fu...@oracle.com <mailto:daniel.fu...@oracle.com> > <mailto:daniel.fu...@oracle.com <mailto:daniel.fu...@oracle.com>>> wrote: > > Hi Arthur, > > 18 // For IPSupport > 19 grant { > 20 permission java.net.SocketPermission "localhost:0", > "listen,resolve"; > 21 permission java.util.PropertyPermission > "java.net.preferIPv4Stack", "read"; > 22 }; > > It might be better if these permissions were granted to the > library only. > > Done. Have you tested that with jtreg? I believe it may not work because of the way the SecurityManager is enabled inside the test (rather than using the jtreg java.security.policy option). You may find that you also need to grant those permissions to jtreg.jar since it is higher in the call stack. If that is the case, you are probably better off granting the permissions to all code, or restructuring the test to use the jtreg java.security.policy option, where jtreg installs its own SecurityManager to grant itself the proper permissions. However, that will require some code changes and granting some additional permissions to the test that are needed (for adding a security provider, etc) before it currently enables a SM. And that is probably more than you want to do for this fix. --Sean Tried it directly with jtreg$ ~/jtreg/build/images/jtreg/bin/jtreg -jdk:./images/jdk/ ../test/jdk/java/security/SecureClassLoader/DefineClass.java and it passes. Verified that removing the newly added permissions makes it fail again. There was some discussion on IPSupport and SecurityManagers when IPSupport was first introduced: https://markmail.org/message/vvemfm367ja3qllj
Ok, the fix looks good then to me. --Sean
