river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Learnings from a RevokeableDynamicPolicy & A Future Roadmap
Date Mon, 16 Aug 2010 03:57:33 GMT
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
>
>   


Mime
View raw message