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

Symbolic link support #54

Open
rektide opened this issue Sep 27, 2022 · 2 comments
Open

Symbolic link support #54

rektide opened this issue Sep 27, 2022 · 2 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest

Comments

@rektide
Copy link

rektide commented Sep 27, 2022

There was a request for symbolic links support (creating & reading links) in WICG/file-system-access#377, but it was closed as being risky to OPFS. I'd like to re-open this request again here.

First, fs work seems like it applies beyond OPFS, & fs ought to be able to encompass one of the most common filesystem capabilities. Second, the security concerns seem like they ought potentially be handleable. Perhaps the api for creating a symlink is attached to a directory, and we limit it to only creating symlinks to it's children.

@a-sully
Copy link
Collaborator

a-sully commented Sep 27, 2022

There was a request for symbolic links support (creating & reading links) in WICG/file-system-access#377, but it was closed as being risky to OPFS. I'd like to re-open this request again here.

To clarify, the risks here are not to OPFS. The risk is that symlinks can be created in a user directory (outside of OPFS) which points to files within the OPFS, since this would effectively bypass the requirement to run Safe Browsing checks and add the Mark-of-the-Web to any file saved to a user's directory.

First, fs work seems like it applies beyond OPFS, & fs ought to be able to encompass one of the most common filesystem capabilities.

This repo only pertains to the OPFS (for now, at least). We could consider supporting symlinks exclusively within the OPFS, but I'm not convinced that provides much value, especially since WICG/file-system-access#377 explicitly wants this to "make working with both a user directory and sandboxed files more seamless together"

Could you explain the use case?

@rektide
Copy link
Author

rektide commented Oct 2, 2022

Could you explain the use case?

I'm trying to write tools to help users deal with git repositories, and there are symlink files in users repos that I need to be able to create on users computers if users are going to have their expected experience. FS gets me most of the way there, but doesn't support this core file type.

The risk is that symlinks can be created in a user directory (outside of OPFS) which points to files within the OPFS, since this would effectively bypass the requirement to run Safe Browsing checks and add the Mark-of-the-Web to any file saved to a user's directory.

Why not have your OS check the symlinked target too? Are there any web specifications for "mark of the web" anywhere we can build off of or work with to help improve this situation? This feels like a pretty baroque concern that shouldn't impede straightforward progress.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest
Development

No branches or pull requests

3 participants