Hi Peter, Something that occurs to me is where does the revoke message come from and who gets?
Also, if I were a malicious programmer, is it possible for me to legitimately get the appropriate permission for something, then intercept and ignore any revokes that come my way? It seems risky if the client code is able to do this, and the master/server/revoker code assumes that it has revoked permissions. It feels like there's a certain amount of trust going on in the form of "If I tell you not to do something, I trust you not to do it." I've got two young daughters; whilst okay, this approach isn't always reliable! :-) Cheers, Tom On Tue, Aug 10, 2010 at 12:05 AM, Peter Firmstone <[email protected]> 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. > > Cheers, > > Peter. > > Fred >> >> >> > >
