RFR 9: JEP 290: Filter Incoming Serialization Data

[Peter Levart]

Hi Roger,


On 07/20/2016 04:44 PM, Roger Riggs wrote:
>>
>> - What is the purpose of the UNDECIDED return? I suspect it is meant 
>> to be used in some filter implementation that delegates the 
>> validation to some "parent" filter and respects its decision unless 
>> it is UNDECIDED in which case it decides (or does not) on its own. 
>> Should such strategy be mentioned in the docs to encourage 
>> inter-operable filter implementations?
> Yes,  some simple filters might be for purposes of black-listing or 
> white-listing.
> The pattern based filters, as produced by 
> ObjectInputFilter.createFilter(patterns), can simply represent
> white or black listing, but if none of the patterns match, it can only 
> report UNDECIDED.
>
> A custom filter, should check if there is a process-wide filter 
> configured and invoke it first.
> Returning its status unless it is UNDECIDED and in that case use its 
> own logic to determine the status.
>
> Definitely worthy of an @apiNote in ObjectInputFilter.

Shoud Config.createFilter(pattern) then have an overload that allows 
specifying a "parent" filter in addition to the "pattern" ?

>
>>
>> - The call-back is invoked after the type of the object and possible 
>> array length is read from stream but before the object's state is 
>> read. Suppose that the object that is about to be read is either 
>> Externalizable object or an object with a readObject() method(s) that 
>> consume block data from the stream. This block data can be large. 
>> Should there be a call-back to "announce" the block data too? (for 
>> example, when the 'clazz' is null and the 'size' is 0, the call-back 
>> reports a back-reference to a previously read object, but when the 
>> 'clazz' is null and the 'size' > 0, it announces the 'size' bytes of 
>> block data. Does this make sense?)
> Interesting case, I'll take another look at that. Since block data 
> records are <= 1024, a filter might not
> have enough information to make an informed decision.  Those bytes 
> would show up in
> the stream bytes but not until the next object is read.

...which could be to late. If the filter is to be also used as a defense 
against forged streams that try to provoke DOS by triggering frequent 
GCs and OutOfMemoryError(s), then such call-back that announces each 
block data record could help achieve that.

Regards, Peter