What was the Java SecurityManager, and what problem was it designed to solve?

## The core idea Normally, any code running in a process can do anything the operating-system user can do: read files, open sockets, delete data, shut the machine down. Java once tried to do something unusual — let **untrusted code** (code you didn't write and don't trust) run inside the *same* JVM process as trusted code, but with **fewer privileges**. The component that enforced that distinction was the **SecurityManager**. ## What it actually was A `SecurityManager` was a single object installed into the JVM. The JDK's own library methods were instrumented: before performing a sensitive action, they asked, "Is there a SecurityManager? If so, may I do this?" Concretely, methods like `FileInputStream`, `Socket`, or `System.exit` called a check such as `securityManager.checkRead(path)`, `checkConnect(host, port)`, or `checkExit(status)`. If no SecurityManager was installed, the check was a no-op and everything was allowed (the default). If one was installed, it decided. ## Permissions and policy Each check ultimately mapped to a **Permission** object — e.g. `FilePermission("/etc/passwd", "read")` or `SocketPermission("example.com:443", "connect")`. A **policy** (usually a text *policy file*, or programmatic policy) granted sets of permissions to code based on where the code came from (its *CodeSource*: a URL/jar) and who signed it. If the running code's granted permissions covered the requested one, the action proceeded; otherwise a `SecurityException` (specifically `AccessControlException`) was thrown. ## The applet sandbox — the reason it existed In the 1990s, web pages could embed **applets**: Java programs downloaded from a website and run inside the browser's JVM. You obviously could not let a random web page read your hard disk or send your files anywhere. So applets ran under a restrictive SecurityManager and policy: no file access, network connections only back to the originating server, no `System.exit`, no native code. Trusted local applications ran with no SecurityManager (full rights). This "same JVM, different privilege levels" model is what the SecurityManager was built for. ## How you turned it on You launched the JVM with `-Djava.security.manager` and optionally `-Djava.security.policy=mypolicy.policy`. You could also install one programmatically (in old Java) with `System.setSecurityManager(...)`. ## Why it is gone The SecurityManager was **deprecated for removal in Java 17 by JEP 411** and is being eliminated. Reasons: (1) applets and Java Web Start — the main untrusted-code use case — died, so the threat model evaporated; (2) it was extremely hard to use correctly and cover completely; (3) it imposed complexity and performance cost on the whole JDK; (4) modern deployments isolate untrusted code at the **OS/container/VM** level (separate processes, namespaces, seccomp, containers) rather than in-process. For *trusted* code, the **Java Module System** (strong encapsulation) provides better integrity guarantees than the SecurityManager ever did. ## Key takeaway The SecurityManager was an *in-process* sandbox for *untrusted* code, gating privileged operations through `checkXxx`/Permission/policy. It made sense for browser applets; with applets gone, it became legacy and is being removed in favor of process/OS isolation and the module system.