ObjectInputStream

[David M. Lloyd]

On 02/29/2012 06:09 PM, Jesse Glick wrote:
> On 02/24/2012 12:26 PM, David M. Lloyd wrote:
>> look at how ObjectInputStream resolves classes by default
>
> ...bizarrely, in fact. In NetBeans we created NbObjectInputStream [1] in
> part to solve this exact problem. (The getNBClassLoader method returns a
> "master" loader, also the default TCCL, which can load from any enabled
> module when unambiguous.)
>
> While NbOIS is a helpful replacement for OIS in module code, if a module
> calls a preexisting library using plain OIS, and this library tries to
> deserialize an instance of a class defined in some unrelated module, you
> are out of luck. Perhaps Jigsaw's ObjectStreamClass should be modified
> to store the module ID where available, which would be easier to use and
> also handle cases where multiple modules define a class of the same name?

Yeah this is exactly what we do in our modular serialization code, 
though the exact moral equivalent to our solution is to subclass 
ObjectInputStream and replace its class resolve methods.  Since we have 
a concept of a module loader, we resolve classes based on their module 
ID with respect to a particular module loader (in our app server we 
typically have two: one for the "static" modules and one which covers 
deployments but also "sees" the static module loader).

So far the results have been quite positive - better than non-modular 
serialization in fact.  Users seem to encounter far fewer CNFE/NCDFE as 
a result of deserialization.

This type of solution should provide for better security as well - a new 
permission type could be introduced which grants deserialize permission 
based upon module ID.
-- 
- DML