RFC: Enhancing Permission Management in Deno with Permission Config Files

[Xiphe]

Summary

This proposal introduces a new approach to managing Deno permissions through dedicated configuration files.
The feature would streamline the process of defining granular permissions for complex projects, while preserving Deno’s security-first philosophy.

By enabling declarative, reusable permission management, this change could significantly improve the developer experience.

Problem Statement

Deno’s explicit permission model is a cornerstone of its security philosophy. However, for more complex projects, managing permissions via CLI flags becomes increasingly cumbersome. Developers face two primary challenges:

1. Long and Granular CLI Flags:
   Maintaining precise permissions (e.g., specific file paths or network domains) often leads to unwieldy command-line invocations that are error-prone and difficult to maintain.
2. Fallback to Full Permissions:
   To avoid the hassle of managing granular permissions, users fall back to granting full permissions (--allow-all), which undermines Deno’s security benefits.

This proposal explores a solution that retains Deno’s explicit permission guarantees while making permission management more practical, especially for larger projects or teams.

Proposed Solution

Introduce a declarative configuration system for permissions using explicitly referenced configuration files. This file would allow developers to define granular permissions in a structured, human-readable format, reducing reliance on verbose CLI flags.

Usage Example

Permission Configuration File (deno-permissions.json)

{
  "read": ["/data"],
  "net": ["api.example.com"]
}

Script Execution

deno run --allow-config=./deno-permissions.json script.ts

This approach enables developers to define permissions centrally, while retaining Deno’s explicit behavior for operations outside the defined permissions.

Interactive Permission Updates

When running a script with a configuration file, Deno’s interactive permission prompts can be extended to include an option to update the configuration file dynamically. If a script requests a permission not included in the config, users could respond with:

• Y: Grant the permission for the session and update the configuration file.

$ deno run --allow-config=./deno-permissions.json script.ts
┏ ⚠️  Deno requests read access to "/[...]/private.file".
┠─ Requested by `Deno.readFile()` API.
┠─ Learn more at: https://docs.deno.com/go/--allow-read
┠─ Run again with --allow-read to bypass this prompt.
┗ Allow? [y/Y/n/A] (y = yes, allow; Y = yes, allow and update ./deno-permissions.json; n = no, deny; A = allow all read permissions) >

If the user selects Y, Deno would append the granted permission to the appropriate section of the config file.

Updated Configuration File

After granting access, the file might look like this:

{
  "read": ["/data", "/[...]/private.file"],
  "net": ["api.example.com"]
}

This mechanism enables iterative refinement of permissions while avoiding manual file edits.

Behavioral Details

Default Behavior

Permissions not specified in the configuration file will fall back to Deno’s standard behavior (e.g., denial or interactive prompts).

Flag Precedence

Explicit CLI flags (e.g., --allow-net=other.com) override permissions in the configuration file to ensure user intent is respected.

Version Control and Caution

While permission configuration files can be shared within a team, care should be taken to ensure permissions are reviewed and granted deliberately. A common pattern could involve:

• Sharing an example file (deno-permissions.example.json) for developers to customize locally.
• Treating permission files as private and ignoring them in version control systems (e.g., .gitignore).

This approach mirrors best practices for managing sensitive files like .env files.

Advantages

1. Improved Usability:
   Simplifies permission management for more complex projects and reduces the verbosity of CLI flags and minimizes errors.
2. Encourages Explicit Permissions:
   By making granular permissions easier to manage, this approach helps developers avoid falling back to full permissions (--allow-all).
3. Dynamic Permission Refinement:
   Interactive updates make it easier to iteratively adjust permissions without manual file edits.
4. Reusable and Shareable:
   Configuration files can be reused across environments and projects, enabling consistent practices.

Conclusion

This idea is intended to make permission management in Deno more practical while maintaining its security-first principles. I am sharing this proposal to gather feedback, learn about potential existing solutions, and discuss whether this approach could benefit the community.

I look forward to hearing your thoughts, ideas, and any suggestions for improvement.

[marvinhagemeister]

Related issue #26372

[Xiphe]

Awesome! Thanks for pointing me towards that!

[Xiphe]

Also related: #12763