doc: document dangerous symlink behavior

Much earlier, a design decision was made that the permission model
should not prevent following symbolic links to presumably inaccessible
locations. Recently, after some back and forth, it had been decided that
it is indeed a vulnerability that symbolic links, which currently point
to an accessible location, can potentially be re-targeted to point to a
presumably inaccessible location. Nevertheless, months later, no
solution has been found and the issue is deemed unfixable in the context
of the current permission model implementation, so it was decided to
disclose the vulnerability and to shift responsibiliy onto users who are
now responsible for ensuring that no potentially dangerous symlinks
exist in any directories that they grant access to.

I believe that this design issue might be surprising and that it comes
with significant security implications for users, so it should be
documented.

Original vulnerability report: https://hackerone.com/reports/1961655

PR-URL: #49154
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>

Author: tniessen

doc/api/permissions.md

@@ -568,6 +568,11 @@ There are constraints you need to know before using this system:
 * Relative paths are not supported through the CLI (`--allow-fs-*`).
 * The model does not inherit to a child node process.
 * The model does not inherit to a worker thread.
+* Symbolic links will be followed even to locations outside of the set of paths
+  that access has been granted to. Relative symbolic links may allow access to
+  arbitrary files and directories. When starting applications with the
+  permission model enabled, you must ensure that no paths to which access has
+  been granted contain relative symbolic links.
 * When creating symlinks the target (first argument) should have read and
   write access.
 * Permission changes are not retroactively applied to existing resources.