Explicit Serialization API and Security

[Chris Hegarty]

On 08/01/15 20:10, Brian Goetz wrote:
>> 1) Validate invariants
>>
>>      A clear and easy to understand mechanism that can validate the
>> deserialized
>>      fields. Does not prevent the use of final fields, as the
>> serialization framework
>>      will be responsible for setting them. Something along the lines
>> of what David
>>      suggested:
>>
>>        private static void validate(GetField fields) {
>>            if (fields.getInt("lo") > fields.getInt("hi")) { ... }
>>       }
>>
>>      This could be a “special” method, or annotation driven. TBD.
>>
>>      Note: the validate method is static, so the object instance is
>> not required to
>>      be created before running the validation.
>
> Sort of...
>
> This is true if the fields participating in the invariant are
> primitives.  But if they're refs, what do you do?  What if you want to
> validate something like
>
>    count == list.size()   // fields are int count, List list
>
> ?  Then wouldn't GetField.getObject have to deserialize the object
> referred to by that field?

Yes it would.

For clarity, I would like to describe how things currently work.

  1) Allocate a new instance of the deserialized type.
  2) Call the first non-Serializable types no-arg constructor
     ( may be j.l.Object ).
  3) For each type in the deserialized types hierarchy, starting
     with the top most ( closest to j.l.Object ),
    3a) create objects representing all fields values for the type
        [this step is recursive and will go to 1 until all
         non-primitive types have been created ]
    3b)  [ holder for invariant validation ]
    3c) assign objects to their respective members of the
        containing instance

[ For simplicity, ignore cyclic references are readObjectXXX for now,
   I will address them separately. ]

Without any user visible side-effects, no readObjectXXX methods, it 
would appear that there is no reason why 1 & 2 must happen before 3a. 
Since objects representing field values are created recursively, then 
all the objects representing the field values are created, per class in 
the hierarchy, before being assigned. If we have no reaObjectXXX 
methods, then the objects being created in 3a could be stored locally, 
repeating 3a as needed, and only assign after all types in the hierarchy 
have been walked. Essentially the sequence of steps could be, 3, 3a+, 
[3b], 1, 2, 3c+.

Given this, an the invariant could be validated at 3b, without the need 
for the creation of the containing object.


Cyclic references: If we encounter a cyclic reference, then we can 
"de-optimize"; stop, create the required instances reachable in the 
graph, fill in whatever fields are currently known, then continue.

readObjectXXX: Since these are instance methods then they must have 
visibility to any deserialized state in the super type. These can be 
handled similarly to cyclic references, but can be determine up front, 
at step 3, rather than in the flow.

-Chris.