History for JavaSecurityModel

??changed:
-
A summary of the Java Security Model

  I've taken a cursory look at the "Java 1.2 Security",
  http://java.sun.com/products/jdk/1.2/docs/guide/security/,
  model for comparison with Zope's present and future models.

  If I've gotten anything wrong or missed something important, 
  I hope someone will correct me.

  Java's security model is based on *classes*, Permissions,
  Policies, and programmer-performed run-time permission checks.

  Permissions -- 
    "Permissions",
    http://java.sun.com/products/jdk/1.2/docs/guide/security/spec/security-spec.doc3.html,
    are abstract objects.  They are defined by a permission class and
    0 or more string parameters.

    Examples:

       - java.lang.RuntimePermission("exitVM")

       - java.net.SocketPermission("*.com","connect")

       - java.io.FilePermission("myfile", "read,write")

    Permissions can imply other permissions. 

  Policies -- "Policies",
    http://java.sun.com/products/jdk/1.2/docs/guide/security/spec/security-spec.doc3.html#20128,
    define *which classes have which permissions*. Policies *no not*
    express *what permissions are needed to use a class*.

    Policies seem to be global settings. There doesn't seem to be any
    notion of server apps that provide different policies for
    different human users.

    Policies are assigned to classes based *either* on **class
    location** or on the **class provider** (*owner*) as expressed
    through a cryptographic signature, where the signature is
    contained in a '.jar' file.

  The last piece of the puzzle is defining what permissions are needed
  to perform actions.  This is done through explicit checks in Java
  code. When a bit of code wants to perform some action that
  should be protected, the code makes an explicit call to check
  whether the calling **classes** have the necessary permission::
    
      !SecurityManager security = System.getSecurityManager();
      if (security != null) {
          !FilePermission perm = new FilePermission("path/file", "read");
          security.checkPermission(perm);
      }

  This seems too hard. There must be an easier way, but I haven't
  found it. (I haven't tried that hard, someone please correct me
  if I'm wrong.) 

  Note that I said **"classes"** above. Normally, **every class in the
  call stack** must have the specified permission or a permission that
  *implies* the specified permission. *Eek!* There is a way to
  short-curcuit this so that the check only goes up to a specified
  boundary.