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). > 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? Fred
