Scoping -P permissions for a simple Vite setup— expected effort?

[hermannsorgel]

Hi all! First, thanks for deno, it helps to learn a lot.

I wanted to be a good citizen and actually scope a minimal permission set for a basic Vite + web extension. You could see that video about how security prompts just train us to hit "allow all" by the end of the day. But I tried:

"permissions": {
  "dev": {
    "read": ["./", "/var", "/private/var/folders/"],
    "write": { "allow": ["./", "/var", "/private/var/folders/st/"], "deny": ["deno.json", "./deno.lock"] },
    "sys": { "allow": ["hostname", "uid", "homedir"] },
    "env": true, 
    "ffi": true,
    "net": { "allow": ["0.0.0.0:5173", "[::]:5173", "127.0.0.1:5173"] }
  }
}

A couple of observations:

Workspace climbing: Vite keep reading all the way up my directory tree looking for project files (like pnpm-workspace.yaml). Dropping an empty yaml in my project root stopped the search, but that feels like a weird workaround. Is there a right way to set a project boundary?

Env & FFI: I eventually had to leave env wide open due to dozens of requested tool-specific variables, and ffi wide open for native build bins. Not a big issue though: probably it is easier to deny access to sensitive values.

Is iterating manually like this pretty much the expected workflow for bundlers right now, or did I miss a smoother trick? I know about DENO_AUDIT_PERMISSIONS but not sure if it helps to find critical permissions (as opposed to permissions we could safely drop).

How do you usually handle the workspace-climbing issue without dropping dummy files around? What's a more practical way to handle deno's permissions??

[darekwojciechowski]

On the workspace-climbing part specifically: that's Vite/pnpm walking up the tree looking for a workspace root, not deno. Your empty pnpm-workspace.yaml works because it's the actual signal both tools use to say "the root is here" — so it's less of a hack than it feels. The cleaner version is to pin the boundary explicitly instead of dropping an empty file: set root in your Vite config to the project dir, and if pnpm is still climbing, add a real pnpm-workspace.yaml (even with just packages: []) as the intended marker.

On env and ffi: leaving those open for a bundler is normal for now — native build tools and their child processes ask for a lot, and there's no reliable static list to allow ahead of time. Denying the few sensitive values (env deny-list for secrets) is the practical move, which is what you landed on.

DENO_AUDIT_PERMISSIONS logs what actually got requested at runtime, so it helps you tighten an over-broad allow-list after a real run — it won't tell you the minimal set up front. So the manual iterate-until-it-runs loop is basically the expected workflow today for bundlers.

[hermannsorgel]

Appreciate the validation, and the vite config tip too, thanks

[lMysticl]

The important split here is Deno vs Vite.

Vite is what walks upward looking for a workspace root. Its documented controls are root for the project root and server.fs.allow for the files the dev server may expose; setting server.fs.allow also disables Vite's automatic workspace-root detection.

DENO_AUDIT_PERMISSIONS is useful, but it only records permission accesses (and optionally stack traces). It does not calculate a minimal safe permission set. I would use it during a real run, then replace the broad permissions in this config with explicit values:

• env: true → the actual variable names or a narrow prefix;
• ffi: true → only the native library paths that the toolchain really loads;
• keep deny rules for secrets, since Deno gives deny precedence over allow.

FFI is the sensitive one: Deno documents that loaded native libraries are outside the runtime sandbox. If the bundler cannot work without broad env/ffi, I would keep that permission set for the development tool only and use a narrower profile for the application itself.

Deno permissions · Deno permission config · Vite server.fs.allow