Bugzilla

The tl;dr general situation here is:
- [GetFilesHelper](https://searchfox.org/mozilla-central/source/dom/filesystem/GetFilesHelper.cpp) will intentionally include symlinks both when specifically selected and when recursively walking a directory.
  - We intentionally enabled this in bug 1274959 with :smaug I think making the policy decision in bug 1274959 comment 1.
  - The bug did [add logic to avoid creating infinite loops when it relates to symlink traversal of directories](https://searchfox.org/mozilla-central/rev/f7edb0b474a1a922f3285107620e802c6e19914d/dom/filesystem/GetFilesHelper.cpp#379).
  - Recursive directory traversal also does not pay attention to conventions about dot-files potentially being hidden.
- Our File/Blob abstractions as returned by the directory picker create the stream without passing `O_NOFOLLOW` or otherwise doing anything that would cause an error when we read the contents of the File.  We have no ability to expose "hey, this is a symlink" to content.
- The general attack model described in this bug:
  - Convince a user to extract an archive which includes symlinks inside a directory hierarchy.
  - Convince the user to then upload the portion of the hierarchy that includes the symlinks, which we will traverse.  Because the symlink can point to anywhere on any path that is accessible to the user running the parent process (modulo some safeguards we have around UNC paths, I think), this can read a lot of potentially sensitive files.

The general options we have here to change the current situation are:
1. Do not expose symlinks ever.  Skip them in directory enumeration, do not let the user pick them individually.
2. Do let the user pick them individually, but skip them in directory enumeration.
3. Only allow symlinks that point within the directory tree that was selected, but as noted, we don't provide the ability to expose metadata about it being a symlink, so this is not particularly useful.
4. Do not expose the contents of the targets of symlinks but display something useless like "this is a symlink to /PATH", which potentially still would include private data.
5. Add a bunch of user prompting that will be hard to explain and where the development is unlikely to happen because it involves touching a lot of things.

:smaug, what are your current views on supporting symlinks given the threat possibilities here?
:dveditz, do we have an existing set of threat models about symlinks and user intent versus social engineering, etc.?

The tl;dr general situation here is:
- [GetFilesHelper](https://searchfox.org/mozilla-central/source/dom/filesystem/GetFilesHelper.cpp) will intentionally include symlinks both when specifically selected and when recursively walking a directory.
  - We intentionally enabled this in bug 1274959 with :smaug I think making the policy decision in bug 1274959 comment 1.
  - The bug did [add logic to avoid creating infinite loops when it relates to symlink traversal of directories](https://searchfox.org/mozilla-central/rev/f7edb0b474a1a922f3285107620e802c6e19914d/dom/filesystem/GetFilesHelper.cpp#379).
  - Recursive directory traversal also does not pay attention to conventions about dot-files potentially being hidden.
- Our File/Blob abstractions as returned by the directory picker create the stream without passing `O_NOFOLLOW` or otherwise doing anything that would cause an error when we read the contents of the File.  We have no ability/desire to expose "hey, this is a symlink" to content via spec semantics.
- The general attack model described in this bug:
  - Convince a user to extract an archive which includes symlinks inside a directory hierarchy.
  - Convince the user to then upload the portion of the hierarchy that includes the symlinks, which we will traverse.  Because the symlink can point to anywhere on any path that is accessible to the user running the parent process (modulo some safeguards we have around UNC paths, I think), this can read a lot of potentially sensitive files.

The general options we have here to change the current situation are:
1. Do not expose symlinks ever.  Skip them in directory enumeration, do not let the user pick them individually.
2. Do let the user pick them individually, but skip them in directory enumeration.
3. Only allow symlinks that point within the directory tree that was selected, but as noted, we don't provide the ability to expose metadata about it being a symlink, so this is not particularly useful.
4. Do not expose the contents of the targets of symlinks but display something useless like "this is a symlink to /PATH", which potentially still would include private data.
5. Add a bunch of user prompting that will be hard to explain and where the development is unlikely to happen because it involves touching a lot of things.

:smaug, what are your current views on supporting symlinks given the threat possibilities here?
:dveditz, do we have an existing set of threat models about symlinks and user intent versus social engineering, etc.?