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.
Cheers,
Peter.
Fred
