capability and permission system

38 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Plugin permissions system overview

Each plugin has a default permission set that contains all permissions and scopes to use the plugin out of the box with a reasonable minimal feature set. For official maintained plugins, the rendered description can be found in the documentation. For community plugins, the default permissions are defined in the plugin source code at your-plugin/permissions/default.toml.

Default permission set structure

A default permission set includes a schema reference, an identifier, a description, and a permissions array listing all permissions and scopes enabled by default. Example from the fs plugin default permissions: permissions array contains ["read-all", "scope-app-recursive", "deny-default"].

Finding plugin permissions locations

For official maintained plugins, permissions are documented in the plugin section of the documentation with rendered descriptions. For community plugins found on crates.io, you need to check the plugin source code for permissions definitions.

Autogenerated permissions in plugins

Plugins like fs have autogenerated permissions that enable or disable individual commands and allow or deny global scopes. These can be found in the plugin documentation or in the plugin source code at fs/permissions/autogenerated.

Adding plugin permissions to capabilities

Plugin permissions must be added to the capabilities section in either src-tauri/tauri.conf.json or in files in the src-tauri/capabilities/ folder. By default, src-tauri/capabilities/default.json can be modified to include plugin permissions.

Custom scopes for specific file access

When autogenerated scopes do not cover the exact access needed, you can configure a custom scope by adding an object to the permissions array with an identifier matching the permission and an allow array specifying paths. Example: {"identifier": "fs:allow-write-text-file", "allow": [{"path": "$HOME/test.txt"}]}

Auto-generate allow and deny permissions for plugin commands

When you add a command to the COMMANDS array in src/build.rs (for example `const COMMANDS: &[&str] = &["ping", "write_custom_file"];`), Tauri's core build system automatically generates `allow-<command>` and `deny-<command>` permissions. These autogenerated permissions will be visible in the `permissions/autogenerated/commands` folder.

Plugin permissions learning tutorials available

Three tutorials are available for learning about plugin permissions: Using Plugin Permissions, Capabilities for Different Windows and Platforms, and Writing Plugin Permissions.

Multi-window capability permission

Both Android and iOS require the core:webview:allow-create-webview-window permission to create new windows from the frontend. Add this to the permissions array in the capability file.

Shell plugin capability configuration for sidecars

In src-tauri/capabilities/default.json, configure shell plugin permissions with a permission object containing identifier 'shell:allow-execute'. The allow array must include an entry with 'name' set to the sidecar path (e.g., 'binaries/my-sidecar'), 'sidecar' set to true, and 'args' set to either true (allowing any arguments) or an array of specific allowed argument values.

Window permissions required for titlebar

The following window permissions must be added to the capabilities configuration to enable titlebar functionality: core:window:default (includes core:window:allow-internal-toggle-maximize), core:window:allow-close, core:window:allow-minimize, core:window:allow-toggle-maximize, and core:window:allow-start-dragging.

Filesystem scope module restructured in Tauri 2

In Tauri 2, scope::FsScope, scope::GlobPattern, and scope::FsScopeEvent were removed. Use scope::fs::Scope, scope::fs::Pattern, and scope::fs::Event respectively.

IPC scope remote domain access changes

In Tauri 2, scope::ipc::RemoteDomainAccessScope::enable_tauri_api and scope::ipc::RemoteDomainAccessScope::enables_tauri_api were removed. Enable each core plugin individually using scope::ipc::RemoteDomainAccessScope::add_plugin instead.

IPC scope module renamed in Tauri 2

In Tauri 2, scope::IpcScope was removed. Use scope::ipc::Scope instead.

Permission system replaces allowlist in Tauri 2

In Tauri 2, the v1 allowlist was replaced with a complete new permission system that works as an access control list (ACL). Create capability files in src-tauri/capabilities folder and Tauri configures everything automatically. The migrate CLI command analyzes v1 allowlist and generates associated capability files.

Removed scope and IPC APIs in Tauri 2.0

Removed scope APIs: 'scope::ipc::RemoteDomainAccessScope::enable_tauri_api' and 'enables_tauri_api' (enable plugins individually via 'add_plugin'); 'scope::IpcScope' (use 'scope::ipc::Scope' instead); 'scope::FsScope', 'scope::GlobPattern', 'scope::FsScopeEvent' (use 'scope::fs::Scope', 'scope::fs::Pattern', 'scope::fs::Event' respectively).

Permission system redesign in Tauri 2.0

v1 allowlist permission system completely redesigned as a new capability-based permission system functioning like an ACL. Allows granting permissions per command, specific windows/domains, and defined access scopes. Create capability files in 'src-tauri/capabilities' folder. The 'migrate' CLI command auto-generates capability files from v1 permission lists.

Core plugins classification

Core pseudo plugins in Tauri 2.0 are those always initialized by Tauri itself and implement the Plugin Trait but cannot be individual crates due to circular dependency concerns. These include path, window, webview, app, image, resources, menu, and tray plugins.

Core plugins namespace prefix

All core pseudo plugins must now be prefixed with 'core:' in capabilities permissions. The namespace 'core:' or the plugin name 'core' are reserved for core pseudo plugins only and will only be initialized if they are in the Tauri codebase. Examples include 'core:path:default', 'core:event:default', 'core:window:default', 'core:app:default', 'core:image:default', 'core:resources:default', 'core:menu:default', and 'core:tray:default'.

Core default permission set

Tauri 2.0 introduced a new special permission identifier 'core:default' which contains all default permissions of all core plugins. This allows developers to simplify permissions boilerplate by using a single 'core:default' entry instead of listing individual core plugin permissions.

Finding plugin permissions documentation

For official Tauri-maintained plugins, default permissions are documented in the plugin documentation (for example, the fs plugin permissions are documented in the official docs). For community plugins, the default permissions are defined in the plugin source code at your-plugin/permissions/default.toml.

Permission denial error message

If a command is denied due to missing permissions, the error message indicates 'fs.<command> not allowed' and lists all the permissions that could enable that command.

Terminology: Permissions vs Capabilities in Tauri

In Tauri documentation, 'Permissions' (アクセス権) refer to specific access grants, while 'Capabilities' (セキュリティ・レベル) refer to security levels that group and organize permissions.

Custom scopes for plugin permissions

For plugins with limited autogenerated scopes, custom scopes can be defined in the capabilities file to restrict access to specific files or paths. A permission with a custom scope is added as an object with 'identifier' and 'allow' properties, where 'allow' specifies path constraints.

Capabilities file location and structure

Plugin permissions can be added either in the src-tauri/tauri.conf.json file in the capabilities section, or in individual files within the src-tauri/capabilities/ folder. By default, src-tauri/capabilities/default.json contains the modifiable security capabilities for the main window.

Automatic permission generation for plugin commands

Tauri's core utilities automatically generate `allow-<command>` and `deny-<command>` permissions for commands defined in a plugin. These autogenerated permissions are automatically placed in the `permissions/autogenerated/commands` folder.

Default plugin permissions configuration

Default permissions for a plugin are defined in the `permissions/default.toml` file. This file should list all permissions that are enabled by default, including autogenerated command permissions like `allow-ping` and `allow-write-custom-file`, in the `[default]` permissions array.

Permission validation and command execution in Tauri 2.0

Tauri's core is able to understand if a command invoke message from a frontend WebView is allowed to reach the command function, and is also able to attach the configured scope to the message. The command implementation is responsible for interpreting and enforcing the scope.

IPC scope removal in Tauri 2.0

Tauri 2.0 removed `tauri::scope::IpcScope` and `tauri::scope::ipc` module and all its types. These were replaced by the new permissions, scopes, and capabilities system.

Default permission policy for Tauri commands

All official Tauri plugin default permissions are reasonably secure by default. As a plugin developer, you can abstract away several base permissions into a `default` permission based on your security assumptions and threat model. As an app developer, you can use, extend, or reduce plugin permissions.

Allowlist system replaced with permissions, scopes, and capabilities

The `allowlist` system in previous Tauri versions was replaced with a new access control system in Tauri 2.0. The new system consists of `permissions` (on-off toggles for Tauri commands), `scopes` (parameter validation for Tauri commands), and `capabilities` (attaching permissions and scopes to Windows and WebViews). This new unified system covers all of Tauri's core API surface and supports app and plugin developers to implement their own access control.

Removed scope modules in Tauri 2.0

Tauri 2.0 removed `tauri::scope::HttpScope`, `tauri::scope::ShellScope`, `tauri::scope::ShellScopeAllowedCommand`, `tauri::scope::ShellScopeAllowedArg`, `tauri::scope::ExecuteArgs`, `tauri::scope::ShellScopeConfig`, and `tauri::scope::ShellScopeError`. These were replaced by the new permissions and scopes system.

Deny scopes always take priority over allow scopes

When both deny and allow scopes are applied to the same command, deny scopes always have priority and will override allow scopes.

Scopes can be applied globally or to specific commands

Scopes can be used by all commands by extending the plugin's global scope, or can be used only for selected commands when combined with specific permissions within an access right.

Scopes define allowed and denied command operations

Scopes in Tauri are a way to finely define what operations a command is allowed or not allowed to perform. Scopes are categorized into allow scopes and deny scopes, with deny scopes always taking priority over allow scopes.

Scope types must be serde serializable

The scope type must be one of the serde-serializable types. These types are typically plugin-specific. For scoped commands implemented in a Tauri application, the scope type must be defined in the application and applied in the command implementation.

Scopes are passed to commands for execution

Scopes are passed to commands, and the command itself is responsible for handling and properly enforcing them.

Scopes can be combined into permission sets

Multiple deny and allow scopes can be merged together into permission sets identified by a unique identifier. This reduces redundant configuration and improves clarity for developers reviewing application settings.

Give your agent this brain