[Feature] dubbo uses setSecurityManager which is now deprecated on JDK 17

[zjf88865]

Pre-check

• [X] I am sure that all the content I provide is in English.

Search before asking

• [X] I had searched in the issues and found no similar feature requirement.

Apache Dubbo Component

Java SDK (apache/dubbo)

Descriptions

dubbo uses setSecurityManager which is now deprecated on JDK 17 , Running untrusted code is a hard problem, and unfortunately history has shown Java's approach to it flawed. Given it's history of vulnerabilities it isn't wildly used and nobody really wants to be responsible for its maintenance.

The future of running untrusted code might be WASM/WASI, although it's not clear to me if there will ever be a system that is resistant to spectre-style attacks. The SecurityManager design was flawed, not because it didn't work (per se), but because it followed an operation-level "deny" model instead of a module-level "grant" model. If an applet wants to read/write files, it has access to the entire java.io package, and so every single method in that package needs to consult the SecurityManager to deny specific operations.

When Java was new, the API was extremely tiny, and so the SecurityManager design made sense because it was easy to identify all the methods that needed a security check. As new JDK features were added, it was easy to make mistakes and let privileged operations be unchecked.

A better model is to define a generic java.io package that just provides basic stream classes, and define a java.file module for file-specific stuff. An applet can access java.io, but it cannot access java.file. Instead, it has a special java.applet.file module it can use. This makes it much easier to lock down the feature set while still allowing new features to be added to the general purpose java.file module.

In theory, the module system provides all the tools for making a better security manager, but sadly, the java.io, java.net, and java.nio packages are all in the base module. Until these packages are broken up (and the original classes deprecated/removed), there's no practical way to support JVM-level security. Instead, applications which want to securely support applets/plugins must run each one in a separate container, with a separate JVM, wasting memory and CPU cycles by doing so.

With the widespread use of spring boot 3，, JDK 8 will certainly become history. If you want to be safe, you should consider the security of running containers, such as using docker, gvisor or firecracker. If you can't achieve absolute security at the operating system level, You might want to look into GraalVM's sandboxes: https://www.graalvm.org/latest/security-guide/polyglot-sandbox/ While it mentions polyglot, it works also with traditional Java. This might be the future solution if you can't allow for process boundaries. rather than the security manage

From a business perspective, jdk8 version 202 or later will be charged. Since dubbo3.3 already supports spring boot3, do we still need to use the expired API? Will there be unpredictable risks with the new version?

Related issues

No response

Are you willing to submit a pull request to fix on your own?

• [ ] Yes I am willing to submit a pull request on my own!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[AlbumenJ]

I cannot find it

[zjf88865]

I cannot find it

![Uploading image.png…]()

[AlbumenJ]

Imgs are broken

[zjf88865]

Imgs are broken

？