tauri-docs icon indicating copy to clipboard operation
tauri-docs copied to clipboard

[bug] Unscoped "fs" permissions don't work unless you specify an "allow"

Open KyleBrown-804 opened this issue 4 months ago • 2 comments

Describe the bug

The issue is that for an fs permission for example fs:allow-exists if you just enable the permission by itself under capabilities/default.json under "permissions", then that does not apply and you will still meet a "forbidden path" error (for example under your /home/ directory).

Not working for a directory /assets under home such as /home/foo/assets: (under src-tauri/capabilities/default.json)

"permissions": [
  "core:default",
  "fs:default",
  "fs:allow-exists"
]

Working for a directory /assets under home such as /home/foo/assets:

"permissions": [
  "core:default",
  "fs:default",
  {
    "identifier": "fs:allow-exists",
    "allow": [{ "path": "$HOME" }, { "path": "$HOME/**/*" }]
  }
]

In both examples using the following JS code with the @tauri-apps/plugin-fs and @tauri-apps/api packages installed:

const home = await path.homeDir();
const localAssetDir = `${home}/foo/assets`;
const assetDirExists = await exists(localAssetDir); // Throws an error "forbidden path: /home/<username>/foo/assets"
console.log(assetDirExists);

Reproduction

  1. Install the File System plugin using the steps provided in the docs here: https://v2.tauri.app/plugin/file-system/#setup
  2. Add the fs:allow-exists permission to the capabilities/default.json file under "permissions".
  3. Create a fake dir under the home directory such as /foo/assets
  4. Use the JS code example given to check for the existence of that path.
  5. Observe the console for a "forbidden path" error being thrown.
  6. Now modify the permission to the format specifying the identifier as the same permission and specifying the home directory and anything within under "allow" like the example above.
  7. Observe the console where now "true" is logged.

Expected behavior

This is either a bug or if the behavior is intended, then it should be more explicitly stated in the docs around permissions and scopes that "allow" is required for it to work.

  • If this is a bug then expected behavior is that setting an unscoped permission works effectively globally (since it's not scoped to any directory).
  • If this is not a bug and is intended behavior, then this should be explicitly stated somewhere in the docs around permissions and scopes sections so it's easier to find for newcomers.

Full tauri info output

tauri info
[✔] Environment
    - OS: Ubuntu 22.4.0 x86_64 (X64) (Unknown DE on Unknown Session)
    - pnpm: 10.16.1
    - npm: 11.6.0

[-] Packages
    - tauri 🦀: 2.8.5
    - tauri-build 🦀: 2.4.1
    - wry 🦀: 0.53.3, (outdated, latest: 0.53.4)
    - tao 🦀: 0.34.3
    - @tauri-apps/api : 2.8.0
    - @tauri-apps/cli : 2.8.4

[-] Plugins
    - tauri-plugin-fs 🦀: 2.4.2
    - @tauri-apps/plugin-fs : 2.4.2
    - tauri-plugin-log 🦀: 2.7.0
    - @tauri-apps/plugin-log : not installed!

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:5173/
    - framework: Vue.js
    - bundler: Vite

Stack trace


Additional context

Mentioned first here in another issue related to "forbidden path" issue from documentation confusion: https://github.com/tauri-apps/tauri/issues/11338#issuecomment-3374770559

KyleBrown-804 avatar Oct 07 '25 01:10 KyleBrown-804

the docs mention this:

[Permissions](https://v2.tauri.app/plugin/file-system/#permissions)
By default all potentially dangerous plugin commands and scopes are blocked and cannot be accessed. You must modify the permissions in your capabilities configuration to enable these.

maybe we should make it clear in the plugin introduction or mention in each api section

lucasfernog avatar Oct 09 '25 11:10 lucasfernog

the docs mention this:

[Permissions](https://v2.tauri.app/plugin/file-system/#permissions)
By default all potentially dangerous plugin commands and scopes are blocked and cannot be accessed. You must modify the permissions in your capabilities configuration to enable these.

maybe we should make it clear in the plugin introduction or mention in each api section

If it's intended behavior then yes, I think it should be more clear, currently "You must modify the permissions in your capabilities configuration to enable these" doesn't specify the how. An explicit example accompanying that I think would help though.

My initial take reading that part of the docs was something like "Okay well I am modifying the permissions under capabilities, I'm setting a top level fs:allow-exists so I would expect that is then permitted globally (without scope) and without needing to specify a directory to where it's allowed. However that isn't the case and you appear to still need to specify explicitly the directory / path in the allow property.

KyleBrown-804 avatar Oct 10 '25 07:10 KyleBrown-804