You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by gt...@apache.org on 2010/11/18 06:06:12 UTC

svn commit: r1036325 [1/3] - in /incubator/river/jtsk/skunk/surrogate: ./ docs/ docs/Management.txt docs/Security.txt nbproject/build-impl.xml nbproject/genfiles.properties nbproject/private/private.properties

Author: gtrasuk
Date: Thu Nov 18 05:06:11 2010
New Revision: 1036325

URL: http://svn.apache.org/viewvc?rev=1036325&view=rev
Log:
Beginning to add in security policy handling, or at least muse on it.

Added:
    incubator/river/jtsk/skunk/surrogate/docs/
    incubator/river/jtsk/skunk/surrogate/docs/Management.txt
    incubator/river/jtsk/skunk/surrogate/docs/Security.txt
Modified:
    incubator/river/jtsk/skunk/surrogate/   (props changed)
    incubator/river/jtsk/skunk/surrogate/nbproject/build-impl.xml
    incubator/river/jtsk/skunk/surrogate/nbproject/genfiles.properties
    incubator/river/jtsk/skunk/surrogate/nbproject/private/private.properties

Propchange: incubator/river/jtsk/skunk/surrogate/
------------------------------------------------------------------------------
--- svn:ignore (original)
+++ svn:ignore Thu Nov 18 05:06:11 2010
@@ -1,2 +1,3 @@
 build
+generated-src
 dist

Added: incubator/river/jtsk/skunk/surrogate/docs/Management.txt
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/skunk/surrogate/docs/Management.txt?rev=1036325&view=auto
==============================================================================
--- incubator/river/jtsk/skunk/surrogate/docs/Management.txt (added)
+++ incubator/river/jtsk/skunk/surrogate/docs/Management.txt Thu Nov 18 05:06:11 2010
@@ -0,0 +1,7 @@
+Management of the container using JMX
+=====================================
+
+- Perhaps the managed objects (e.g. classloaders, app environments, etc) should
+implement the MBean protocol/annotation.  JSR160 provides for registration of
+proxies in the lookup service, and it looks like it isn't too hard to integrate
+JMX.

Added: incubator/river/jtsk/skunk/surrogate/docs/Security.txt
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/skunk/surrogate/docs/Security.txt?rev=1036325&view=auto
==============================================================================
--- incubator/river/jtsk/skunk/surrogate/docs/Security.txt (added)
+++ incubator/river/jtsk/skunk/surrogate/docs/Security.txt Thu Nov 18 05:06:11 2010
@@ -0,0 +1,39 @@
+
+Security in the Container
+=========================
+
+- We need to provide the following:
+    - All permissions for container implementation code.
+    - Limited permissions as defined for surrogates in each surrogate
+    operating environment.  It's possible that different surrogates might have
+    different permissions sets according to some criteria (don't know what that
+    might be, perhaps different permissions for different connectors)
+    - Limited permissions for other applications loaded into the container
+    - Support for dynamic assignment of permissions to proxies by the proxy
+    verifiers, such as would be allowed by DynamicPolicyProvider.
+    - Should probably still support UmbrellaGrant, same as FilePolicyProvider.
+
+- Some observations:
+    - we have a more complicated class loader structure than contemplated by
+    the PolicyFile provider.
+    - in particular, in a Jini environment, grants to a codebase are pretty
+    meaningless.  Grants to code signed by a particular entity are OK
+    - In all likelihood, we would have a policy file per application deployed
+    to the container.
+    - Would probably like to support a default application policy and then
+    allow the container admin to replace that with a customized policy file for
+    a particular application.
+    - Since we are creating the classloader as an instance of our own
+    classloader, we can provide a customized protection domain as well.
+
+- Tentative plan:
+    - Create a parser that reads a limited version of the permissions file
+    (like no codebase, no keystore lines) and creates permissions set from it.
+    - Each application gets a protection domain; protection domain is taken
+    from a per-app security config.
+    - Default config provided, but is overridden by per-app config.
+    - Maybe: app can have its own config file in META-INF.  When app is started,
+    that file will be used unless it over-reaches the permissions allowed by the
+    default or per-app config.
+    - Implement a Policy that includes functions of DynamicPolicyProvider, but
+    otherwise goes to the protection domain for the permissions.