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