Fist of all, thanks for the useful feedback....
On Monday 05 January 2004 17:32, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> I like the approach although think we need to separate the declaration
> of permission requirement from the granting of permissions. > <type>
> <info>
> <name>demo</name>
> <lifestyle>singleton</lifestyle>
> </info>
> <permissions>
> <permission class="java.awt.AWTPermission"
> name="accessClipboard" />
> </permissions>
> </type>
OK, now you are introducing "Permission Requirement" as a formal declaration.
I like to HAVE that, but not so fond to MAKE it happen ;o)
I also think that the "meta-info attribute" (is that correct terminology)
should be "permission-requirements" to more explicitly show that it is NOT
permissions granted.
Also, I would like to have the @permission-requirement as close to the code as
possible, method level, and that the "meta generator" can aggregate it.
> Then at the container level, we can declare the granting of permissions
> based on the declarations (as per what you described above).
The main point here is also that it would be possible to detect some of the
possible mismatches and warn against that SecurityExceptions may follow and
why.
Another issue, experimentation will tell, is about "soft" requirements of
"names", such as FilePermission's path in the meta-info declaration,
especially for tieing the argument to context entries. Wow... It almost blow
my mind thinking of it.
> > 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.
"Vetoed"?? java.security has no such concept :o)
I hope you realize that "Avalon Code" is not infering any security rules
whatsoever, that is left to java.security as in all restricted execution
environments.
What will actually happen is that for each container invoked (both throught
the deploy() method) as well as every service interface method, the system
must combine the "current" AccessControlContext (which is part of the Thread)
with the declared one for the container.
I think it will basically be something like this in AbstractBlock.deploy();
PermissionModel permModel = clModel.getPermissionModel();
AccessControlContext acc = permModel.getAccessControlContext();
AccessController.doPrivileged( new PrivilegedActionException()
{
public void run() throws Exception
{
appliance.deploy();
}
}, acc );
In the PermissionModel, the getAccessControlContext() would be aggregated from
each of the permissions for the classloader.
(Now I just realize that the <permissions> should actually be per
"<classpath>" element, and not really for the whole container. Need to
evaluate that.)
And inside the PermissionModel, there is some "nice things" that must happen,
since the execution thread probably don't have access to the
AccessControlContext, so that must all happen in a AllPermission worker
thread started by the kernel.
The worker basically needs to do;
AccessControlContext execAcc = m_InFifo.get(); //from execution thread.
AccessControlContext assignedAcc =
new AccessControlContext( m_ProtectionDomains );
AccessControlContext newAcc =
new AccessControlContext( m_DomainCombiner, assignedAcc );
m_OutFifo.put( newAcc );
The ProtectionDomains (and the assignedAcc above) needs to be done early, for
performance.
Talking of Performance, the required code makes me a bit nervous :o)
Fairly expensive to make a service interface call. Have to look into some
optimizations (one that springs to mind, is having a single
AccessControlContext for the root container and below :o( Experimentation
will tell. ).
> > ( 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.
If the "permission-requirements" are in place, the tools will make this more
of a breeze. (Somehow, the .xinfo info for the container must be reachable
somewhere, right?)
> > 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.
So far so good. The PermissionModel is a delegate of the entries in the
classloader section. No problem.
> 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).
****** beep **** beep *** beep - "System Overload" - ** beep * beep beep
BOOM!!!
And since you now brought up "permission-requirements", assembly will need to
pick that up for each component, and figure out if there is a "reasonable
match" or not.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
