Explicit Serialization API and Security
Chris Hegarty
chris.hegarty at oracle.com
Wed Jan 14 11:37:26 UTC 2015
Peter F,
I am still struggling with the basic concept of you proposal. Let me see
if I understand it correctly. Does the following describe a similar
scenario as you envisage:
1) For each Serializable type, T, in the deserialized types
hierarchy, starting with the top most ( closest to j.l.Object ),
1a) Read T's fields from the stream, fields
1b) validate(t, fields) // t will be null first time
1c) allocate a new instance of T, and assign to t
1d) set fields in t
2) Return t;
So for each level in the hierarchy, an instance of a type is created
only after its invariants have been checked. This instance is then
passed to the next level so it can participate in that levels invariants
validation.
If this scenario is along the same lines as yours, then I just don't see
how 1c above will always be possible.
If we could somehow make the object caller sensitive until after
deserialization completes, then could avoid having to try to allocate
multiple instance down the hierarchy.
-Chris.
On 13/01/15 10:24, Peter Firmstone wrote:
> Could we use a static validator method and generate bytecode for
> constructors dynamically?
>
> The developer can optionally implement the constructors.
>
> static GetField invariantCheck(GetField f);
>
> Create a caller sensitive GetField implementation and add a two new
> methods to GetField:
>
> abstract Object createSuper(); // to access superclass object methods
> for inavariant checking.
>
> abstract Class getType(String name);
>
> Set fields from within constructors.
>
> The generated constructors are straight forward:
>
> 1. Call static method.
> 2. Call super class constructor with result from static method.
> 3. Set final fields
> 4. How to set transient fields, implement a private method called from
> within the constructor?
>
> Require a permission to extend GetField?
>
More information about the core-libs-dev
mailing list