Gang,
Since deployment went fairly well, I now want to look into codebase level Security (scheduled for 3.4).
NOTE!!! Please don't confuse this with Subject level Security and JAAS leveraging. That is the next step. This must be sorted out first.
I have in mind that for each container's classloader declaration, the permissions are given;
<container> <classloader>
<classpath> : </classpath>
<permissions>
<permission class="java.util.PropertyPermission" name="java.home" actions="read" />
<permission class="java.io.FilePermission"
name="${merlin.home}/temp/"
actions="read,write" />
<permission
class="java.awt.AWTPermission"
name="accessClipboard" />
</permissions>
</classloader>
</container>
I hope you get the idea...
I like the approach although think we need to separate the declaration of permission requirement from the granting of permissions. A permission requirement should be associated with a component Type (i.e. in meta-data) either implicitly or explicitly. Implicit permissions can be established relative to things like a component declaration of a context entry such as "urn:avalon:home" or "urn:avalon:temp". Explicit permission requirements such as accessClipboard could be exposed as follows:
<type>
<info>
<name>demo</name>
<lifestyle>singleton</lifestyle>
</info>
<permissions>
<permission class="java.awt.AWTPermission"
name="accessClipboard" />
</permissions>
:
</type>Then at the container level, we can declare the granting of permissions based on the declarations (as per what you described above).
For nested containers, I am planning to require that the outer container also declares the nested container's requirements.
Given that a nested container is basically simulating a component, the set of permissions granted by a nested container constitute the requested permissions that the nested container is making on its parent. Therefore the inclusion (statically or dynamically) of a sub-container can be vetoed by the parent container.
( It would be a typical job for GUI tool to aggregate the security permissions up the hierarchy. )
Possibly a combination of GUI tool and a build-time validation plug in.
I am not planning to have the assembly figure out if the permission declarations are "compatible", i.e. if the inner-container is requesting more permissions than its parent container. At least not initially. I think that is also more of a tool thing.
I think you need to think about this up-front but I also don't think it's too big an issue.
I think that the only position where the access control context can safely be established is in the BlockInvocationHandler and the ApplianceInvocationHandler, which are dynamic proxies forwarding the call to the component.
The main "hurdle" I see now is to get the permission elements into the ClassloaderModel instance, which will create the access control context.
The ClassLoaderModel would need to be expanded to include expose of a PermissionModel. The PermissionModel would be driven off a meta-data definition - e.g. PermissionsDirective containing multiple PermissionDirective instances. The PermissionsDirective would be created using XMLContainmentProfileCreator (and would need to be externalizable through XMLContainmentProfileWriter).
A PermissionModel would be instantiated using the PermissionsDirective meta-data as part of the ClassLoaderModel creation (which is where the classloader is itself created).
Cheers, Stephen.
Any comments so far???
Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- |------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/ | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
