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 Tue, 10 Aug 2010 11:40:23 GMT
Peter Firmstone wrote:
> Fred Oliver wrote:
>> Peter,
>> Thanks again.
>>>> Further, the
>>>> revocation events are delivered to one or more of the delegates to
>>>> force the socket to close.
>>> That was the original intent, however, now I'm thinking the delegate 
>>> catch
>>> AccessControlException, thrown by a helper class, called
>>> MethodAccessContoller, which the delegate calls prior to entering the
>>> privileged block, performs any clean up, then re-throws the 
>>> exception.  Code
>>> that doesn't need to do any clean up, doesn't need to catch the 
>>> exception.
>> What happens to the thread stuck in the read on the socket when the
>> permission it had to read was revoked after the read began? Force
>> closing the socket will free up the thread. Otherwise the thread would
>> eventually obtain data it shouldn't have from this read (or hang
>> indefinitely waiting for data).
> Hmm, yes, it needs to be closed from another thread.
>>> Basically: Method call from new thread? Permission check.  Permission
>>> revoked? Permission check again.  Previously checked Thread, no 
>>> relevant
>>> revocation's since (of same Class<Permission>)? Don't check again, 
>>> return
>>> quickly.
>>> The assumption I've made is, it will be very difficult for an 
>>> attacker to
>>> predict when a thread will access a method on the delegate, then 
>>> later, be
>>> called by that very same thread, so his class can call the delegate
>>> unchecked.  Any thoughts on this?  Am I overlooking something?
>> What happens when a delegate is passed back and forth between trusted
>> (having permission) and untrusted (not having permission) code (on the
>> same thread)? If you cached based on the thread, you'll get
>> unpredictable results?
> Yes that is a problem, so we have take a snapshot of the 
> AccessControlContext at the time of the permission check and check 
> that it is still equal() later.  I guess I could drop the thread check 
> and just check the AccessControlContext, this might be useful for 
> thread groups etc ;)
> The AccessControlContext could be cached for each Thread.

Yes, I think I'll keep a HashSet containing the AccessControlContext's 
that have passed with checkPermission, then if the Set contains the 
current AccessControlContext, we don't need to check it again.  When a 
revocation occurs the Set will be cleared.

I'm going to optimise the revocation strictly to only advise the 
delegates based on the Permission Classes, registered by the delegate's 
themselves, when they register with the policy (not individual 
Permission's since they may imply each other, just the common Class 
type).  Since the policy notifies the delegate, it also gets to close 
any sockets etc.

This should be the most optimum solution,  certainly much less work than 
calling checkPermission on every method invocation, but with no security 
trade off's.

N.B. Your time is much appreciated, thanks for the help.


> Cheers,
> Peter.
>> Fred

View raw message