Should path restrictions use --allow-read= prefix or runtime permission queries for file access?

Direct Answer

For applications that must conditionally grant file access based on user input or configuration, runtime permission queries (Deno.permissions.query() and Deno.permissions.request()) are the better fit. Static --allow-read=/path flags enforce a fixed allowlist at startup and cannot adapt to runtime decisions.

Confirmed Facts

• --allow-read implements a deny‑by‑default posture that is immutable for the process lifetime.
• Deno.permissions.query({ name: "read", path: "..." }) returns the current permission state without prompting.
• Deno.permissions.request({ name: "read", path: "..." }) triggers a user prompt (in interactive terminals) and can expand the allowlist at runtime.
• Flag‑based restrictions can cause third‑party modules to fail if they access directories not explicitly whitelisted.
• Runtime requests may be denied, so every file operation must handle PermissionDeniedError.

Likely Explanation (Subject to Verification)

Static flags give stronger guarantees because the OS‑level sandbox is configured before any user code runs. Runtime queries shift the responsibility to application logic, which increases flexibility but also the surface for bugs. On Windows, path normalization differences (e.g., drive letters, case‑insensitivity) can cause a path that passes a flag check to resolve outside the intended directory; Unix‑like systems are generally stricter but symlinks can still bypass restrictions if not resolved.

Steps for a Conditional‑Access Application

1. Start the process with the minimal set of --allow-read paths that are always required (e.g., application config directory).
2. When user input or configuration indicates a new directory, call Deno.permissions.query() to see if access is already granted.
3. If not granted, call Deno.permissions.request() and handle the returned PermissionStatus.
4. Wrap every file‑system call in a try/catch for Deno.errors.PermissionDenied and provide a user‑friendly fallback.

Verification You Can Run

# 1. Static enforcement test
deno run --allow-read=/tmp test_read.ts
# test_read.ts attempts to read /etc/passwd – should fail

# 2. Query current permission
deno run --allow-read=/tmp query_test.ts
# query_test.ts: console.log(await Deno.permissions.query({name:"read", path:"/tmp"}))

# 3. Interactive request test (requires a TTY)
deno run request_test.ts
# request_test.ts: const status = await Deno.permissions.request({name:"read", path:"/home/user/docs"});
# Observe the prompt and result

One Diagnostic Detail That Changes the Recommendation

Does your application run in an interactive terminal where user prompts are feasible? If the answer is no (e.g., a CI pipeline, a server daemon, or a compiled binary), Deno.permissions.request() will always resolve to "denied" without user interaction, making static flags the only reliable option.

Assumptions & Uncertainty

• Assumes Deno 1.x/2.x permission model; behavior may differ in future releases.
• Path resolution quirks on Windows (junctions, case folding) are not fully characterized here – mark for review if targeting Windows.
• Third‑party module permission needs are inferred from common patterns; audit each dependency.