Explicit Serialization API and Security

Peter Levart peter.levart at gmail.com
Wed Jan 7 16:02:11 UTC 2015


On 01/07/2015 03:54 PM, Chris Hegarty wrote:
> On 06/01/15 17:49, Peter Levart wrote:
>> On 01/06/2015 06:21 PM, Chris Hegarty wrote:
>>> On 6 Jan 2015, at 15:06, Peter Levart <peter.levart at gmail.com> wrote:
>>>
>>>> On 01/06/2015 04:03 PM, Peter Levart wrote:
>>>>> private void readObject(ObjectInputStream in) throws IOException,
>>>>> ClassNotFoundException {
>>>>>         ObjectInputStream.GetField fields = in.readFields(); // this
>>>>> already validates the types
>>>> Well, not true currently. But type validation could be added at this
>>>> point.
>>> Right. I think I’ll file a bug to track this as it seems reasonable to
>>> add type validation to readFields and defaultReadObject. So we can
>>> probably assume/ignore it in this discussion.
>>>
>>> I like the idea of a callback into the serialization framework to
>>> handling the setting of final fields, after validation. I played a
>>> little with your patch and added it to a branch in the sandbox**
>>>
>>> So a simple example, without legacy fields, might looks as below (
>>> without the need for writeObject or serialPersistentFields ). The
>>> simple validating readObject is starting to look like boilerplate ?
>>
>> Well, 1st and last line are always the same, yes. What's between them is
>> what you would have to write in a special check-only method too.
>
> I guess what I'm getting at is, if you want just invariant checking, 
> then maybe something like this would be more readable:
>
>     @SerialInvariantChecker()
>     private static void validate(@SerialParam(name="lo", 
> type=Integer.class)int lo,
>                                  @SerialParam(name="hi", 
> type=Integer.class)int hi)
>     {
>         if (lo > hi)
>             throw new IllegalArgumentException("lo:" + lo + " > hi:" + 
> hi);
>     }
>
>    ... and the serialization machinery would call this when appropriate.

Nice.

We have method parameter names accessible via reflection since JDK8 and 
types have always been, so no @SerialParam is necessary.

Peter

>
> -Chris
>
>
>> Regards, Peter
>>
>>>
>>> public class SimpleInterval implements Serializable {
>>>
>>>      private final int lo, hi;
>>>
>>>      private static void validate(int lo, int hi) {
>>>          // invariant
>>>          if (lo > hi)
>>>              throw new IllegalArgumentException("lo:" + lo + " > hi:"
>>> + hi);
>>>      }
>>>
>>>      public SimpleInterval(int lo, int hi) {
>>>          validate(lo, hi);
>>>          this.lo = lo;
>>>          this.hi = hi;
>>>      }
>>>
>>>      public int getLo() { return lo; }
>>>
>>>      public int getHi() { return hi; }
>>>
>>>      private void readObject(ObjectInputStream in) throws IOException,
>>> ClassNotFoundException {
>>>          ObjectInputStream.GetField fields = in.readFields();
>>>
>>>          // validate 'lo' and 'hi' fields invariant
>>>          int lo = fields.get("lo", 0);
>>>          int hi = fields.get("hi", 0);
>>>          validate(lo, hi);
>>>
>>>          // set current fields from read data
>>>          fields.defaultReadFields(); // this is new API!
>>>      }
>>> }
>>>
>>> -Chris.
>>>
>>> ** hg clone http://hg.openjdk.java.net/jdk9/sandbox sandbox
>>>      cd sandbox
>>>      sh get_source.sh
>>>      sh common/bin/hgforest.sh update -r serial-exp-branch
>>>
>>>      I also added your example, etc, under:
>>>        jdk/test/java/io/Serializable/invarientChecker
>>>
>>>      see http://cr.openjdk.java.net/~chegar/docs/sandbox.html
>>>
>>




More information about the core-libs-dev mailing list