I think this is fine. The same coder is used for encode and decode, so the Class object should be the same as well. Inheritance is not part of the Beam model (thank goodness) so this is a language-specific concern. As far as the model is concerned, the full URN and the payload of the coder is its identity and coders with different identities have no inheritance or compatibility relationship. Pipeline snapshot/update is an edge case, but changing coder is not supported by any runner I know of, and probably won't be until we have some rather large new ideas.
Kenn On Thu, Mar 19, 2020 at 4:50 AM Colm O hEigeartaigh <[email protected]> wrote: > Hi, > > I have a question on SerializableCoder. I'm looking at hardening the Java > Object deserialization that is taking place. We have a "Class<T> type" that > is used to decode the input stream: > > ObjectInputStream ois = new ObjectInputStream(inStream); > return type.cast(ois.readObject()); > > What I would like to do would be something like: > > ObjectInputStream ois = new ObjectInputStream(inStream) { > @Override > protected Class<?> resolveClass(ObjectStreamClass desc) throws > IOException, ClassNotFoundException { > if (!desc.getName().equals(type.getName())) { > throw new InvalidClassException("Unauthorized deserialization > attempt", desc.getName()); > } > return super.resolveClass(desc); > } > }; > return type.cast(ois.readObject()); > > This would prevent a possible security hole where an attacker could try to > force the recipient of the input stream to deserialize to a gadget class or > the like for a RCE. > > The question is - does the deserialized type have to correspond exactly to > the supplied Class? Or is it supported that it's a base type / abstract > class? If the latter then my idea won't really work. But if the type > corresponds exactly then it should work OK. > > Thanks, > > Colm. >
