L1nq0 commented on issue #9073: URL: https://github.com/apache/storm/issues/9073#issuecomment-5525366572
Before opening a PR I'd like to align on the design, since there are a few viable shapes that trade differently: 1. **Worker-JVM-wide default filter.** Add a default `-Djdk.serialFilter=<deny-list of known gadget packages>` to `worker.childopts` in `conf/defaults.yaml`. Zero Java code (a JVM-wide filter applies to every `ObjectInputStream` in the worker, including the fallback bridge), and it also covers the other native deserialization points in the worker (worker hooks, custom stream groupings, thrift-serialized component objects). Downsides: it changes default behavior for every deployment on upgrade; sites that override `worker.childopts` wholesale silently lose it; a gadget deny-list is a permanent maintenance surface; and it risks reading as "the fallback is now safe enough", which the security docs rightly push back on. 2. **Bridge-scoped programmatic `ObjectInputFilter`.** Install a filter in `SerializableSerializer.read` (where the fallback performs a raw `ObjectInputStream.readObject()`), driven by a new config key, default empty (opt-in). Precise scope (exactly the documented-risky data path), no global default change, and it also covers `LocalCluster`, where `worker.childopts` never applies. 3. **Docs-only recipe.** No code; add a security-docs recipe for "if you must run with the fallback, configure `jdk.serialFilter` like this". Zero behavior change, but no default protection. My lean is (2) with an empty default: it adds a precise, explicit control exactly where the docs already warn, changes no default behavior, and keeps the security message intact (the fallback stays discouraged; if you must run it, here is a filter). I'd pair it with the docs recipe from (3). (1) works too if you prefer the JVM-wide defense-in-depth angle. One scoping note from looking at this: besides the fallback bridge, the worker JVM deserializes native objects at a few other points (worker hooks, custom stream groupings, trident bolts, thrift-serialized component objects) — all fed by topology-defined, submitter-supplied bytes rather than runtime data. A JVM-wide filter would cover those too, which is the main argument for (1). Which of these fits Storm best — or if none of them does, what direction would you take? Once we agree I'll put up the PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
