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, 09 Aug 2010 23:05:10 GMT
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.



> Fred

View raw message