Explain how AccessController.doPrivileged worked together with checkPermission and the call-stack-based permission model.

## Why a stack walk? The SecurityManager had to answer: "is *this* operation allowed *right now*?" The danger is **confused-deputy** attacks — untrusted code tricking trusted code into doing something privileged on its behalf. Java's answer was a **stack-based access control** model: an operation is permitted only if **every method currently on the call stack** is allowed to do it. ## Protection domains Every class belongs to a **ProtectionDomain**, derived from its **CodeSource** (where it came from — a jar/URL, and signers) and the **permissions** the policy grants that source. Trusted local code might have `AllPermission`; downloaded applet code might have almost none. ## The check Sensitive JDK methods called `securityManager.checkPermission(perm)` (or a convenience `checkRead`/`checkConnect`, which built the right Permission and delegated). That delegated to `AccessController.checkPermission(perm)`, which **walked the stack** from the current frame outward. For each frame it took that frame's ProtectionDomain and asked, "does this domain imply the requested permission?" If **any** frame's domain did **not** imply it, the walk threw `AccessControlException` (a subclass of `SecurityException`). So the *effective* permission set was the **intersection** of every caller's permissions — the least-privileged caller on the stack constrained everyone. This is what stopped untrusted code from "borrowing" a trusted method's rights merely by calling it. ## The problem this creates Intersection-of-callers is safe but too strict. Consider a trusted utility — say a logging framework — that must read **its own** configuration file. If sandboxed application code (with no `FilePermission`) calls `log.info(...)`, the untrusted frame is on the stack, so the intersection excludes file reads, and the legitimate config read fails. The trusted library *should* be allowed to read *its own* file regardless of who called it. ## AccessController.doPrivileged — the escape hatch `doPrivileged` told the stack walk: **stop here**. When trusted code executed an action inside `AccessController.doPrivileged(PrivilegedAction)`, the access-control stack walk terminated at that frame and considered only **that code's own** ProtectionDomain, ignoring callers further out (the untrusted ones). So the logging library wraps its config read: ```java String cfg = AccessController.doPrivileged( (PrivilegedAction<String>) () -> readConfigFile("logging.properties")); ``` Now the read succeeds on the library's permissions even when invoked from sandboxed code. There were variants: `PrivilegedExceptionAction` (for checked exceptions), and overloads taking an `AccessControlContext` to *combine* a previously captured context (so you grant only the intersection of "my rights" and "the rights at the time the context was captured"). ## The danger of doPrivileged `doPrivileged` is a **privilege-escalation primitive**. If a library does something privileged with **attacker-controlled input** inside `doPrivileged` — e.g. opens whatever file *path the untrusted caller passed in* — it becomes a hole: the caller couldn't open that file directly, but the deputy does it for them. Rules: keep the privileged block **small**, do a **fixed, well-understood** action, **don't** pass untrusted arguments into it, and don't return capabilities (open streams, references) that leak privilege back to the caller. ## Why this whole model is being removed The stack-walk model is subtle, easy to get wrong, expensive (it instrumented hot JDK paths), and tied to the now-dead applet use case. JEP 411 deprecated the SecurityManager — and with it `AccessController`/`doPrivileged` — for removal. Modern code is migrating off these APIs; isolation moves to the process/OS/container boundary. ## Key takeaway Permission checks walked the stack and required *every* caller to have the permission (intersection rule), preventing confused-deputy escalation; `doPrivileged` stopped the walk so trusted code could act on its own authority — a powerful but dangerous escape hatch that must never launder untrusted input.