<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Making things clearer if I can:</p>
    <p>Some thoughts on hooks:</p>
    <ul>
      <li>Utilize java.security.Provider, so as not to expose jdk
        implementation code.  Eg: a module declaration or
        META-INF/services/java.security.Provider to obtain relevant
        instances of java.security.Guard, where Permission
        implementation types are currently used. </li>
      <li>Allow existing Permission classes to remain backward
        compatible, declare them as services, so that SecurityManager
        can be degraded as planned and Permission implementations can be
        gradually removed as planned. (Removes dependencies on
        Permission instance types).<br>
      </li>
      <li>Guard implementation's are typically required to have a
        constructor with two String arguments, (String name, String
        actions), can be passed as new String[]{ name, actions}
        constructor parameter to
        java.security.Provider.Service::newInstance.</li>
      <li>Service must implement Guard interface, with Guard::check
        method (current Permission implementations implement this method
        and call System.getSecurityManager).<br>
      </li>
      <li>Doesn't depend on Permission or any existing implementation
        classes, completely customizable by the service implementation.</li>
      <li>Application developers can also implement hooks using this
        service.</li>
      <li>Using security provider avoids deadlock during Provider
        initialization, it must be listed as a provider in the
        java.security file or if security.overridePropertiesFile=true
        and -Djava.security.properties=<a class="moz-txt-link-freetext" href="file://path/additional.security">file://path/additional.security</a>
        defines providers, which would be useful for testing.</li>
    </ul>
    <p>Break up guard service providers into current Permission types
      (independent instances to avoid circular deadlocks), developers
      only need implement those relevant to them and may only use checks
      for users if they wish:</p>
    "AWT"<br>
    "FILE"<br>
    "SERIALIZABLE"<br>
    "MANAGEMENT"<br>
    "REFLECT"<br>
    "RUNTIME"<br>
    "NET"<br>
    "SOCKET"<br>
    "URL"<br>
    "FILE-LINK"<br>
    "SECURITY"<br>
    "SQL"<br>
    "LOGGING"<br>
    "PROPERTY"<br>
    "MBEAN"<br>
    "MBEAN-SERVER"<br>
    "MBEAN-TRUST"<br>
    "SUBJECT-DELEGATION"<br>
    "TLS"<br>
    "AUTH"<br>
    "KERBEROS-DELEGATION"<br>
    "KERBEROS-SERVICE"<br>
    "PRIVATE-CREDENTIAL"<br>
    "AUDIO"<br>
    "JAXB"<br>
    "WEB-SERVICE"
    <p>I would like to suggest adding a new provider type:</p>
    "PARSE-DATA" - To be called by any code about to parse data, eg
    deserialization, XML, JSON, SQL, etc.  Granted to users, so that it
    can only be performed after authentication.
    <pre class="moz-signature" cols="72">-- 
Regards,
 
Peter Firmstone
Zeus Project Services Pty Ltd.</pre>
  </body>
</html>