Permissions & the Default Set

"A permission is one specific power with a name. Learn to read the name and the whole system stops being mysterious."

Reading a Permission Identifier

Permissions are strings with a readable structure: <source>:<name>. The source is core (built-in Tauri) or a plugin name (fs, dialog, shell, store…). The name is either a curated set like default or a single granular grant like allow-read-text-file. So core:default is 'the baseline safe core APIs,' fs:allow-read-text-file is exactly 'may read a text file,' and shell:allow-execute is 'may run a process.' Once you can parse the name, you can grant precisely.

Default Sets vs Granular Grants

Most plugins ship a default permission that bundles the commonly-needed, reasonably-safe commands — a sensible starting point. When default grants more than you need, drop to individual allow- permissions and list only the specific commands your app calls. Granular is more typing and far less attack surface; for anything powerful (filesystem, shell), prefer the granular list over the convenient default.

Allow and Deny

Permissions come in allow- and deny- forms, and deny wins. You can grant a broad set and then explicitly deny a dangerous corner of it — a belt-and-suspenders move. If a command mysteriously refuses to run even though you granted it, check whether a deny permission (or a scope) is overriding your allow. The precedence is deliberate: deny is how you carve exceptions out of a grant.

Code

Granting specific powers, not broad ones·json

// Permission identifiers, parsed:
//   core:default                     baseline safe core APIs
//   core:window:allow-set-title      one specific window power
//   fs:allow-read-text-file          read a text file (plugin: fs)
//   dialog:allow-open                show an open-file dialog
//   shell:allow-execute              run a process (powerful!)

{
  "identifier": "main-caps",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "dialog:allow-open",          // granular: just the open dialog
    "fs:allow-read-text-file"     // granular: read text, nothing else
    // note: NO shell, NO fs write — not needed, not granted
  ]
}

Exercise

Add the dialog plugin to your app and grant ONLY dialog:allow-open (not dialog:default). Call the open dialog from the frontend and confirm it works. Then try a different dialog command you didn't grant (like save) and watch it fail with a permission error. You've felt granular permissions allow exactly one thing and deny the rest.

Hint

Add tauri-plugin-dialog, then put dialog:allow-open in your capability. The save dialog will be blocked because you only granted open — that denial is the lesson, not a bug.