-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feat] Ability to disallow previously added files/directories in FsScope #7366
Comments
I think this sounds reasonable, if you want, please open a PR for |
Sure thing @amrbashir, but the function names |
totally forgot about |
I am using it in the case of switching between workspaces. If I close a workspace and add it to forbidden, I won't be able to open it back up because forbidden takes priority over allowed. And there's no functionality to remove from forbidden set either. Though, the reset method alone would be enough for my use case. |
I see, then a PR to add |
A more specific "forget" function with the same api as the allow / forbid functions was requested a lot of times already. So imho we need both, a complete reset function, and a more granular one for specific patterns. |
@FabianLars Is this something that could be added in the mentioned #7371 PR? If so, how would the function signatures and events look? pub fn forget_allowed_directory<P: AsRef<Path>>(&self, path: P, recursive: bool) -> crate::Result<()>
pub fn forget_allowed_file<P: AsRef<Path>>(&self, path: P) -> crate::Result<()>
pub fn forget_forbidden_directory<P: AsRef<Path>>(&self, path: P, recursive: bool) -> crate::Result<()>
pub fn forget_forbidden_file<P: AsRef<Path>>(&self, path: P) -> crate::Result<()>
pub enum Event {
PathAllowed(PathBuf),
PathForbidden(PathBuf),
AllowedPathForgotten(PathBuf),
ForbiddenPathForgotten(PathBuf),
Reset, // Would a reset event need to be emitted?
} Also, this is how the reset signature looks in the PR: pub fn reset<R: crate::Runtime, M: crate::Manager<R>>
// Usage:
scope.reset(&app, &app.config().tauri.security.asset_protocol.scope).unwrap(); |
At first i meant to say yes, but with the event enum it will be tricky since it's not marked as Also, i'd lean towards just having one forget function (well, one for files, one for dirs) which covers both the allowed and forbidden patterns but idk |
Yeah a separate PR targeting v2 for the @FabianLars @amrbashir Not sure what would be the best option but I suggested that a |
I don't necessarily like adding |
We'll have to be careful with things like the dialog and filedrop scope modifications then, which probably isn't a huge deal. Also, cc @lucasfernog (Amr's last comment) |
This is something we need to discuss with the security team too. But personally I prefer having a forget function than dealing with infinite allow/forbid priority (which also polutes the scope if you keep forbidding and allowing a path). |
Describe the problem
An application might need to switch to a different workspace / folder which has been allowed via the FsScope api during runtime. This feature would allow the removal of previously added paths from the allowed scope.
Describe the solution you'd like
Add two functions
disallow_directory
anddisallow_file
which resembles theallow_file
andallow_directory
functions found in fs.rs but instead of adding the paths to the allowed set, the disallow functions would remove the path.Alternatives considered
An alternative solution would be to have a function to reset the scope to the FsAllowlistScope configuration (initial config from app start). This could also solve the problem described above.
Additional context
I wrote some code that does this and tested it on Windows. It's not too big of a change and I would be happy to make a pull request if this is something that should be added to Tauri. The "reset" alternative might be a simpler solution for my problem, but there might be a use case for removing certain added paths but not others.
The text was updated successfully, but these errors were encountered: