Open rnarubin opened 6 years ago
rnarubin commented on Dec 11, 2017
I'm sure that terrible things could be done with the futures returned by locks and semaphores. I think this comes down to how optimistic we are of our userbase. Nobody cooperative would do this, but if we imagine that some security conscious library wanted to use our library in their own (and exposed to other users) then this could become an attack vector. I don't know how far our responsibility can be expected to go though.
In a particularly narrow case where a future isn't transformed before returning to user space (straight from new CompletableFuture()
) we could extend the class and override toCompletableFuture
to return a copy. This would solve the malicious completion in AsyncFunnel and FairAsyncLock for example, and the cost would be minimal -- only the copy on a call to toCompletableFuture
which as mentioned elsewhere is a pain in the ass method anyway. The only downside is that the safety isn't preserved across transformation, which means we'd have to carefully watch how we use such futures internally (once a user has called the transform our internal state is safe)
Porting issue 37 from the enterprise repo
rkhadiwa commented on Nov 29, 2017
To what extent do we need to defend against a user who backdoors past the "read only"
CompletionStage
withcs.toCompletableFuture().complete(t)
(or the more sinistercs.toCompletableFuture.obtrudeValue
) ?For example,
AsyncFunnel
gives out the sameCompletableFuture
to many distinct users. Not sure if there are any other APIs where this matters.In JDK9 they added
CompletableFuture.copy()
/CompletableFuture.minimalStage
presumably because they realized this is a problem. Should we defensively copy anyCompletableFuture
we hand out that could be reused? Seems pretty costly to defend against something that no sane user would actually do.See http://cs.oswego.edu/pipermail/concurrency-interest/2016-July/015299.html