Tauri ACL/Allowlist v2 Implementation and Plugin System Refactor

[tweidinger]

This PR contains several (breaking) changes related to:

• Tauri plugins
• The new allowlist
• Tauri build process

The current proposal and extended documentation for these changes can be found in a public HackMD document here. This document will be undergoing several changes during the implementation but shows the general approach and architecture. We strongly recommend reading this document before commenting.

We currently believe this is the one big major change needed to make v2.0 feature complete for a beta/rc/release,
therefore work on this PR should be prioritized.

Tauri Plugins

In v2 of Tauri most of the commands were moved into dedicated plugins and outside of the core of Tauri.
The move to plugins rendered the existing allowlist unusable, as the system was not designed to be compatible with plugins or code outside of Tauri. This PR addresses this by adding a new allowlist and access control for Tauri commands written by app or plugin developers.

The plugin-workspace repository contains all of the previous (and more) functionality now available as plugins (see the v2 branch). This reduces the amount of complexity in Tauri itself. Additionally, it allows more fast paced changes of system interaction functionality, as no complete understanding of Tauri itself is needed to contribute. It also allows breaking releases/changes to specific plugins independently from Tauri.

To further define what Tauri plugins are and what they need to implement the tauri-plugin crate was created.
It can be found in core/tauri-plugin in this PR branch.
Plugin developers need to depend on this crate and implement the defined traits, define default permissions and optionally define scope types.

A lot of work (not tracked here) is required to upgrade plugins from v1 to v2 and convenience tooling like tauri plugin init, tauri permission init/add/remove needs to be created, while existing tooling like tauri-cli and create-tauri-app need to be changed to be compatible with the new permissions/capabilities/plugins.

Allowlist

In v1 of Tauri most of the commands were Tauri internal APIs built into the core of Tauri. The allowlist was used to restrict the access from the Webview to the Tauri core and system resources.

With this PR the new allowlist is built in a way to be used by all plugins and application developers and is no longer exclusive for Tauri inbuilt functionality. It also allows more fine grained control, while being able to abstract away a lot of things.

We introduce several new naming conventions and move the allowlist to a capability driven configuration. Permissions define command enablement and scope, while capabilities link permissions with windows of the application.

A simplified example allowlist/capabilities configuration could look like:

"capabilities": [
    {
        "context": "local",
        "windows": [
            "*"
        ],
        "permissions": [
            "fs:full-homefolder-access",
            "fs:block-homefolder-sensitive-access"
        ]
    }
]

with an example permission, which could also be inbuilt/defined by the fs plugin:

{
    "version": 1,
    "identifier": "full-homefolder-access",
    "description": "This allows read write access to the complete $HOME folder.",
    "commands": {
        "allow": [
            "fs:readDirectory",
            "fs:readFile"
        ]
    },
    "scope": {
        "allow": [
            {
                "path": "$HOME/**"
            }
        ]
    }
}

or even simpler when the capabilities are further abstracted:

"capabilities": [
        "default",
        "admin-windows"
]

Tauri Build System

The build system will be enhanced (most likely) in a non-breaking way to understand metadata information provided by plugins and will allow us to pass information from plugins into the Tauri application.
It also will allow us to highlight issues to the application developer when commands are enabled in the capabilities but the plugin implementing these commands is not initialized/used. Also the other way around when no commands of a plugin are enabled but the plugin is initialized.

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

Related issues:

• [feat] Allow window labels regex or prefix for remote domain access scope #7461 the new v2 implementation will deprecate the dangerousRemoteIPCAccess as it will be part of the capability definition

[chippers]

This looks good as a basis for the ACL. There are some improvements I have in a project for this rep that we ideally land before stable, but I think we can mark this PR as complete and a good MVP