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...
For nested containers, I am planning to require that the outer container also
declares the nested container's requirements.
( It would be a typical job for GUI tool to aggregate the security permissions
up the hierarchy. )
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 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.
Any comments so far???
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
