GEODE-3923 changes have been merged to develop life as you know it will
change a bit. The merge implements serialization
white-listing/blacklisting and to insure that we have white-listed the
correct set of classes, and that no new Geode classes are introduced
that aren't properly registered, *all unit tests will be run with
white-listing enabled*.
*What is white-listing?* It's basically telling Geode to only
deserialize instances of known classes. You turn it on with a new cache
property, validate-serializable-objects. You white-list a
java-serializable class by creating a pattern that matches your class
using the new cache property serializable-object-filter. There are
numerous examples of this in the merged test code.
DataSerializable classes do not need to be whitelisted unless they are
sometimes java-serialized, such as being a value in an array of Objects
that is serialized with DataSerializer.writeObject(). I've run into a
few of those.
*Example:*
validate-serializable-objects=true (default is false except for
distributedTests)
serializable-object-filter=org.apache.geode.test.query.TestObject;org.apache.geode.test.functions.*
*What happens if you neglect to whitelist your class?* Your test will
fail and you will see an InvalidClassException in your test output. You
should search for "rejecting" in the output to find the classes that you
need to whitelist.
*How are Geode classes white-listed?* Everything that is in
sanctionedSerializables.txt is automatically white-listed. The
AnalyzeSerializablesJUnitTest has new test methods that ensure that all
classes in the "sanctioned" file can be serialized and deserialized. It
also ensures that classes listed in the excludedClasses.txt file can not
be serialized and deserialized and that none of them are also in the
sanctionedSerializables.txt white-list.
*Which commit did this to me?*
a2bd5788d0b0728d91d551ddaac878b336d7892a was the merge to develop. The
commit message has additional details:
commit a2bd5788d0b0728d91d551ddaac878b336d7892a
Author: Bruce Schuchardt <bschucha...@pivotal.io>
Date: Thu Nov 30 14:25:48 2017 -0800
GEODE-3923 Provide whitelist/blacklist capability for java
serialization
This is a squashed and rebased commit of the work from the now-defunct
whitelist-wip branch. The work allows you to whitelist and blacklist
use of Java deserialization for classes matching a pattern you provide.
All distributedTests are now run with this enabled and with the default
blacklist pattern of "!*", which blacklists everything not explicitely
allowed by Geode in the sanctionedSerializables.txt files or by
your test.
Each layer needing one now has its own sanctionedSerializables.txt file
that is a resource in the product tree. These are installed as
whitelists
by a new DistributedSystemService in that layer.
There are numerous examples of whitelisting classes in the tests.
If you do not whitelist your class Geode will throw an
IncompatibleClassException.
If you happen to run into this look in your logs for "rejecting"
and you
can easily find the name of the offending class and add it to your
whitelist.
Two new cache properties have been added:
validate-serializable-objects
If true checks incoming java serializable objects against a filter
(allows
internal Geode classes and any others provided in the
serializable-object-filter property).
If you enable this property you must be using Java 8 build 121 or
later.
If you are not Geode will throw an exception and refuse to start.
Default: "false"
serializable-object-filter
A user provided whitelist of objects that the system will allow to
serialize.
See java.io.ObjectInputFilter.Config for details on the syntax for
creating filters.
https://docs.oracle.com/javase/9/docs/api/java/io/ObjectInputFilter.Config.html
Default: "!*"
