Fred Oliver wrote:
Why not have
ECM.checkPermission(Collection<Permission>)
instead of the begin/check/end block? Would this remove the Thread
object from those maps?
No the finally block is to prevent a method returning, while revocation
is underway, and allow a Reaper to clean up before it returns.
What if a delegate requires multiple permissions of different classes
from multiple ECMs? Should this be done at the RevokeableDynamicPolicy
level instead? Should the ECM be hidden from the public API?
No there's only one ECM per policy, it is concurrent, but blocks during
revocation.
I was looking at writing a SocketDelegate and I' m not clear on some things.
Excellent!
- How do I get a reference to the system RevokableDynamicPolicy object?
I need to add a static method to net.jini.security.Security.
- Once I have it, how do I check for actual permission to do
something? Is there a utility to iterate through the list of
PermissionGrants? Or some other method?
Not yet, but that is my intent, to create a utility to iterate through
the permission grants. Perhaps we could have a utility method on
RevokeableDynamicPolicy, since it caches the Permission's during the
GrantPermission checks, to avoid a PermissionGrant implementer from
using mutability to elevate privileges. It wouldn't be too difficult to
iterate through them, using implies(ProtectionDomain). I'm going to
change the array of Permission's returned from a PermissionGrant back to
an unmodifiable collection, as per your suggestion, to enforce
immutability, it also removes one copy operation and makes iteration
simpler.
- If we have class based ECM (which seems simpler), then should
Class<? extends Permission> appear in many places where Permission
currently appears? e.g.
RevokableDynamicPolicy.getExecutionManager(Class<? extends Permission>);
Controller.revoke(Set<Class<? extends Permission>> classes);
Controller.getPermission() returns Class<? extends Permission>
Controller.getECManager(Class<? extends Permission>);
Controller.pool uses Class<? extends Permission> as key?
I've removed controller, got rid of the static caches as you suggested.
I've uploaded ExecutionContextManager and ECM onto
svn for review:
org.apache.river.imp.security.policy.se.ECM
org.apache.river.api.security.policy.ExecutionContextManager
The RevokeableDynamicPolicy is an interface, there's also a
RevokeableDynamicPolicySpi, so we can utilise different features on
different java platforms, such as concurrency etc.
In Controller, do the pool and cont fields need to be separate? If the
weak references get cleared at different times, then these two
structures can briefly diverge. Is this OK?
Do you still have ECM.addAction()?
No, it's now ECM.begin(Reaper), where Reaper extends Runnable, it's
given the thread we want to prevent from returning security sensitive
information. I'm still not sure if this is the right way to handle it
yet. I've thought about throwing an AccessControlException from the
end() method if any Permission's are revoked, this gives someone trying
to debug more information, it still requires the delegate have a reaper
to clean up. Feel free to play with it, modify it on svn.
The ECM.addAction() takes a
Runnable, which gets the job done. I'm concerned that this requires
that delegates implement Runnable,
No just a private implementation within the delegate. It can be as
simple as interrupting the thread in question if that's the desired
behaviour, that would probably cause confusion during debugging. This
is why I'm thinking about throwing an AccessControlException from the
end() method in the finally block.
in conflict with some other use of
Runnable. Perhaps it's worth adding an interface for this like
RevocationListener with a permissionRevoked() method.
Most of the methods in the delegates get called from the untrusted
code, but the run() method does not.
- When the run() method is called (on which thread?)
It's called from a small thread pool, within the ECM.
, how does it
determine which codebase or principal (etc.) to use when checking
permissions? How does a socket delegate know to close a socket?
It will be from the AccessControlContext, the Reaper will have it's
ProtectionDomain on the stack at the time.
Have a look on svn, you might have a better idea, the delegate has to
associate the Reaper with the method at the moment. I'm not entirely
comfortable with the Reaper.
Cheers & Thanks,
Peter.
Fred
