river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Oliver <fkoli...@gmail.com>
Subject Re: Learnings from a RevokeableDynamicPolicy & A Future Roadmap
Date Mon, 09 Aug 2010 22:21:19 GMT
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

Mime
View raw message