JEP415: FilterInThread Example

[Roger Riggs]

Hi Heinz,

Indeed, this example is not intuitive and does not do what was intended 
and could use a better explanation.

The interaction of three filters gets complicated and their combination 
depends on the ordering and intention of each filter and the particular 
filter factory goal. The FilterInThread example provides only one of 
many possible functions.

The FilterInThread example uses the JVM-wide filter, thread filter, and 
stream filter for different purposes.

The JVM-wide filter has a particular role in that it can be set on the 
command line via a system property.
It is typically used as a backstop after the application is deployed to 
patch in additional rejection of classes.
The property value syntax allows for either allowing or rejecting 
classes, and an otherwise unmentioned class is left UNDECIDED, possibly 
with some risk exposure.

The thread filter is used to more focus de-serialization on a group of 
classes, either to narrow it or expand it.

The FilterInThread example takes the position that any UNDECIDED in the 
thread's filter and the JVM-wide filter should be rejected even if the 
pattern does not explicitly do so.  This keeps an oversight in filter 
construction from becoming a risk.

The stream filter is included mostly for backward compatibility, 
introduced in JDK 9 via JEP 290. The stream filter is set by the code 
creating the ObjectInputStream and part of its design and purpose. In 
the FilterInThread example, if it returns UNDECIDED, the result is 
determined by a merge of the other two filters and further rejecting 
UNDECIDED.

The bug in the example, that individually rejects UNDECIDED in the 
JVM-wide and thread filters respectively, should instead reject only if 
both return UNDECIDED.

The revised example is:

*// Returns a composite filter of the static JVM-wide filter, a 
thread-specific filter, *// and the stream-specific filter. *public 
ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter next) 
{ *if (curr == null) { *// Called from the OIS constructor or perhaps 
OIS.setObjectInputFilter with no current filter *var filter = 
filterThreadLocal.get(); *if (filter != null) { *// Merge to invoke the 
thread local filter and then the JVM-wide filter (if any) *filter = 
ObjectInputFilter.merge(filter, next); *return 
ObjectInputFilter.rejectUndecidedClass(filter); *} *return (next == 
null) ? null : ObjectInputFilter.rejectUndecidedClass(next); *} else { 
*// Called from OIS.setObjectInputFilter with a current filter and a 
stream-specific filter. *// The curr filter already incorporates the 
thread filter and static JVM-wide filter *// and rejection of undecided 
classes *// If there is a stream-specific filter merge to invoke it and 
then the current filter. *if (next != null) { *return 
ObjectInputFilter.merge(next, curr); *} *return curr; *} *}


The filters are evaluated as:
merge(restrictLargeArrays,rejectUndecidedClass(merge(allowInteger,allowArrayList)))

The first call to the factory returns a filter:  `var f1 = 
rejectUndecidedClass(merge(allowInteger,allowArrayList))`
The second call to the factory returns filter: `var f2 = 
merge(restrictLargeArrays, f1)`

The filters are evaluated in order, until an accept or reject is returned:
   1) restrictLargeArrays  (stream)
   2) allowInteger            (thread filter)
   3) allowArrayList         (JVM-wide filter)

This has the same value as your ideal but without an extra 
RejectUndecidedClass.

Note that in this composition, the choice by a filter to accept or 
reject can not be overridden by a subsequent filter.

Thank you for the comments and suggestions, Roger

On 2/3/23 1:20 PM, Dr Heinz M. Kabutz wrote:
> I was trying to get my head around the FilterInThread example in JEP 
> 415 (https://openjdk.org/jeps/415) and the JavaDoc for the 
> ObjectInputFilter 
> (https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/ObjectInputFilter.html)
>
> For example, let's assume we have three filters. The first allow 
> ArrayList, the second allows Integer, the third restricts arrays to 
> not be larger than 1000.
>
>     ObjectInputFilter allowArrayList = ObjectInputFilter.allowFilter(
>             Set.of(ArrayList.class, Object.class)::contains, UNDECIDED
>     );
>     ObjectInputFilter allowInteger = ObjectInputFilter.allowFilter(
>             Set.of(Number.class, Integer.class)::contains, UNDECIDED
>     );
>     ObjectInputFilter restrictLargeArrays =
> ObjectInputFilter.Config.createFilter("maxarray=1000");
>
> Let's say that we create a FilterInThread instance and install that as 
> our factory. Furthermore, we set the allowArrayList as the global 
> serial filter. When we call filterInThread.doWithSerialFilter() we 
> pass in the allowInteger filter. Lastly, during the actual 
> deserialization, we call setObjectInputFilter() on the 
> ObjectInputStream with the restrictLargeArrays filter. Ideally, I 
> would want the final filter to look like this:
>
> rejectUndecidedClass(merge(restrictLargeArrays,merge(allowInteger,allowArrayList))) 
>
>
> However, in the FilterInThread example, we add the 
> rejectUndecidedClass() wrapper around each of the steps. Thus we would 
> get something like:
>
> rejectUndecidedClass(merge(restrictLargeArrays,rejectUndecidedClass(merge(allowInteger,rejectUndecidedClass(allowArrayList))))) 
>
>
> Thus we could never allow any classes except for ArrayList.
>
>
> Regards
>
> Heinz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230205/473a6346/attachment-0001.htm>