skip to content

Name the common built-in Permission classes and what each protects. How does AllPermission differ from a specific permission?

level: middleimportance: nice to knowfreq 18%

answer

  1. File / Socket / Runtime / Property / Reflect permissions
  2. File+Socket have actions; Runtime is name-only
  3. implies() only within the same class
  4. AllPermission implies everything = sudo for code
  5. <<ALL FILES>> = whole filesystem

basics

~20 s

FilePermission guards file access, SocketPermission guards network connections, and RuntimePermission guards JVM abilities like exiting the VM. AllPermission is a wildcard that grants everything at once, so it implies any other permission and should almost never be granted.

solid answer

~40 s

The legacy model ships several Permission subclasses, each protecting a category of operation. FilePermission targets a path with actions read/write/execute/delete. SocketPermission targets host:port with actions connect/accept/listen/resolve. RuntimePermission has no actions — its name alone is the capability (exitVM, createClassLoader, setSecurityManager, getClassLoader, etc.). Others include PropertyPermission (read/write system properties), ReflectPermission (suppressAccessChecks for reflection), NetPermission, and SecurityPermission. AllPermission is the catch-all: its implies() returns true for every permission, so granting it disables fine-grained control entirely — it's the equivalent of 'sudo for code' and is a red flag in any policy except the bootstrap/JDK code. Compared with a specific permission, AllPermission carries no target or actions to scope; it's all-or-nothing.

go deeper

for a junior

Can name FilePermission, SocketPermission, RuntimePermission and what they broadly guard, and that AllPermission grants everything.

for a middle

Knows the target+actions vs name-only distinction, the common wildcards, and that AllPermission.implies() is always true.

for a senior

Adds that implies() never crosses permission classes, knows the less-common ones (Property/Reflect/Security), and flags AllPermission grants in review.

for a principal

Reasons about least-privilege policy authoring as a whole, why the model is hard to get right, and treats AllPermission to non-bootstrap code as an audit finding while noting the model's deprecation.

## The categories of capability The permission model splits sensitive operations into typed buckets. Each bucket is a `Permission` subclass; you scope it with a **target** and (sometimes) **actions**. | Class | Protects | Target | Actions | |---|---|---|---| | `java.io.FilePermission` | Filesystem access | a path (`/tmp/*`, `/tmp/-`, `<<ALL FILES>>`) | read, write, execute, delete, readlink | | `java.net.SocketPermission` | TCP/UDP networking | host\:port range (`example.com:443`, `*:1024-`) | connect, accept, listen, resolve | | `java.lang.RuntimePermission` | JVM-level abilities | a dotted name (`exitVM`, `createClassLoader`, `setSecurityManager`, `getClassLoader`, `modifyThread`) | *(none — name is the whole capability)* | | `java.util.PropertyPermission` | System properties | property name (`user.home`, `*`) | read, write | | `java.lang.reflect.ReflectPermission` | Reflection bypass | `suppressAccessChecks` | *(none)* | | `java.net.NetPermission` | Networking internals | e.g. `setDefaultAuthenticator` | *(none)* | | `java.security.SecurityPermission` | Security config | e.g. `getPolicy`, `setPolicy` | *(none)* | Key points to internalize: - **Actions vs no actions.** FilePermission and SocketPermission are *target + actions*. Most others (RuntimePermission, ReflectPermission, SecurityPermission) are *name-only*: holding the named permission is the entire grant, there's nothing finer to specify. - **Wildcards in targets.** FilePermission uses `*` (this directory) and `-` (this directory recursively); `<<ALL FILES>>` matches the whole filesystem. PropertyPermission uses `*` or a `prefix.*`. SocketPermission supports port *ranges* (`1024-`, `-1023`, `80-90`). - **implies() is per-class.** A permission only ever implies another of the **same class** (a FilePermission never implies a SocketPermission). Within a class, broader target/actions imply narrower ones. ## AllPermission — the wildcard of wildcards `java.security.AllPermission` is special: its `implies(p)` returns **true for any p of any class**. Granting it is equivalent to turning the sandbox off for that code: ``` grant codeBase "file:/opt/trusted/-" { permission java.security.AllPermission; }; ``` That block lets the code do *anything* — read any file, open any socket, exit the VM, replace the security policy. It is normally reserved for the JDK's own bootstrap code (which lives in a domain with AllPermission so the platform itself isn't sandboxed). Seeing `AllPermission` granted to application or, worse, downloaded code is a serious finding: it defeats the entire purpose of the model. Contrast with a specific permission: `FilePermission "/tmp/*","read"` is *scoped* — it grants exactly one capability over one location. AllPermission has no target and no actions because it is not scoped at all. ## Status reminder All of these classes still exist in the JDK, but the SecurityManager that consults them is deprecated for removal (JEP 411). The classes are useful to *recognize* — they also appear in old stack traces and policy files — but the enforcement they fed is on its way out.

  • Which permission would code need to call System.exit, and what is its target?
    RuntimePermission with the name 'exitVM' (more precisely 'exitVM.{status}', e.g. exitVM.0, or exitVM.* for any status). It has no actions — the name is the capability.
  • Why is granting AllPermission usually a security red flag?
    Its implies() returns true for every permission of every class, so the code can do anything — read any file, open any socket, change the policy, exit the VM. It nullifies fine-grained access control and is meant only for trusted JDK/bootstrap code.

saying these in an interview costs you the question

  • Granting AllPermission to application or downloaded code — it defeats the whole sandbox.
  • Expecting a FilePermission to imply a SocketPermission — implies() never crosses permission classes.
  • Thinking RuntimePermission has read/write actions — it is name-only.
  • Confusing the * (one level) and - (recursive) wildcards in FilePermission targets.

context

resolving links…