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

Author: tniessen

doc/api/permissions.md

@@ -550,6 +550,10 @@ 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. In particular, the mere existence of a single
+  relative symbolic links within any accessible directory may allow an attacker
+  to access arbitrary files and directories.
 * When creating symlinks the target (first argument) should have read and
   write access.
 * Permission changes are not retroactively applied to existing resources.