{"version":"2.1.317","anchor":"symlinked-denywrite-and-deny-scrub-handling-hardened-tengu","canonical_anchor":"symlinked-denywrite-and-deny-scrub-handling-hardened-tengu","heading":"Sandbox stops following some symlinks in write-protected paths","tier":"notice","area":"Sandbox","scope":"both","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317\/e\/symlinked-denywrite-and-deny-scrub-handling-hardened-tengu","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317","markdown":"### Sandbox stops following some symlinks in write-protected paths\n\nBehind a server switch, the sandbox no longer follows a write-protected symlink that points at another host or cannot be safely checked\n\n**Unclear.** What this switch does when the server sends nothing is not settled, so it is unclear whether the new handling applies to you by default.\n\n**What**\n\nIn the sandbox, `denyWrite` lists places commands may not write to. A symlink is a file that points at another location. Before, the sandbox always followed a symlink in that list, up to 8 hops, and protected wherever it ended up. Behind a server-controlled switch, it now handles them differently:\n\n- A symlink that points at another host, or that cannot be checked without following it, is not followed. The sandbox logs this and keeps protecting the symlink's own path.\n\n- Symlinks that have been replaced get a new decision: follow, keep or refuse.\n\n- Symlinks that point at nothing are also handled differently.\n\n**Why**\n\nThis closes a way of redirecting a write-protection rule to somewhere else by changing where a symlink points.\n\n- Area: Sandbox\n- Names: `denyWrite`\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 3\/5\n- Scope: both\n- Heads-up: no"}