<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 1/14/19 9:39 AM, Vladimir Kozlov
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:e158a7b4-dd42-8d20-b5f1-aa7a3d4c014e@oracle.com">Thank
      you, Alan
      <br>
      <br>
      On 1/14/19 2:27 AM, Alan Bateman wrote:
      <br>
      <blockquote type="cite">On 13/01/2019 02:46, Vladimir Kozlov
        wrote:
        <br>
        <blockquote type="cite"><a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~kvn/8216151/webrev.00/">http://cr.openjdk.java.net/~kvn/8216151/webrev.00/</a>
          <br>
          <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8216151">https://bugs.openjdk.java.net/browse/JDK-8216151</a>
          <br>
          <br>
          Have to update default.policy after changes in
          jdk.internal.vm.compiler.management files done by JDK-8199755:
          "Update Graal".
          <br>
          <br>
          Ran CheckAccessClassInPackagePermissions.java test.
          <br>
          <br>
        </blockquote>
        cc'ing security-dev as that is where is the security policy file
        is maintained.
        <br>
        <br>
        One thing is double check is that code in
        jdk.internal.vm.compiler.management really needs to access
        members of classes in the listed packages. I ask because the
        module definition doesn't export some of these packages to
        jdk.internal.vm.compiler.management so they aren't accessible
        even when not running with a security manager.
        <br>
      </blockquote>
      <br>
      I verified that all listed packages are used by
      compiler.management and I listed only needed in default.policy. I
      used CheckAccessClassInPackagePermissions.java test to find which
      permissions are needed.
      <br>
      <br>
    </blockquote>
    <br>
    I reviewed the change and the list matches the list of qualified
    exports from jdk.internal.vm.compiler to
    jdk.internal.vm.compiler.management.<br>
    <br>
    The security team has been looking into removing the private VM call
    out to ClassLoader::checkPackageAccess.  When that's removed, we
    would not need to maintain these accessClassInPackage permission to
    access any new qualified exports.<br>
    <br>
    Mandy<br>
  </body>
</html>