Skip to content
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

Handling * paths in --allow-fs-* flags #1116

Open
RafaelGSS opened this issue Sep 22, 2023 · 4 comments
Open

Handling * paths in --allow-fs-* flags #1116

RafaelGSS opened this issue Sep 22, 2023 · 4 comments

Comments

@RafaelGSS
Copy link
Member

Currently, the * char in --allow-fs-read or --allow-fs-write makes use of a wildcard pattern. Consider the following list:

  • --allow-fs-read=/tmp/* - allows read access to all files and folders under /tmp/.
  • --allow-fs-read=/tm* - allows read access to all files and folders starting with /tm* i.e. /tm2.txt or /tmp/file.txt

While this might save quite some time when using the permission model, * is a valid path character and we should be able to handle it, in this case, ignoring the wildcard approach.

@tniessen
Copy link
Member

The same probably applies to process.permission.has().

Copy link
Contributor

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

@github-actions github-actions bot added the stale label Dec 22, 2023
@RafaelGSS RafaelGSS removed the stale label Dec 26, 2023
Copy link
Contributor

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

@RafaelGSS
Copy link
Member Author

I will leave this issue open, but, I have a feeling the trade-off of removing wildcards to handle specific cases where the file path contains the "*" is not worth it. So, I have stopped the work on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants