RFR 9: JEP 290: Filter Incoming Serialization Data
peter.levart at gmail.com
Thu Jul 21 07:42:23 UTC 2016
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
> 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.
More information about the core-libs-dev