permission: check symlink target in cpSync

[fg0x0]

What

Add permission checks for symlink target paths in CpSyncCopyDir (src/node_file.cc).

Why

fs.cpSync with recursive: true copies symlinks via std::filesystem::create_symlink() and copy_symlink() without validating the symlink target against the permission model. This allows reading and writing files outside permitted paths through copied symlinks.

fs.symlinkSync was fixed for this in the CVE-2025-55130 patch (lines 1353-1357) but the same check was not added to cpSync.

Reproduction

mkdir -p /tmp/allowed/src /tmp/allowed/dest /tmp/denied
echo SECRET > /tmp/denied/secret.txt
ln -sf /tmp/denied/secret.txt /tmp/allowed/src/link

node --permission \
  --allow-fs-read=/tmp/allowed --allow-fs-write=/tmp/allowed \
  --allow-fs-read=/usr --allow-fs-read=/lib -e '
const fs = require("node:fs");
try { fs.readFileSync("/tmp/denied/secret.txt"); } catch(e) { console.log("blocked:", e.code); }
try { fs.symlinkSync("/tmp/denied/secret.txt", "/tmp/allowed/dest/link"); } catch(e) { console.log("blocked:", e.code); }
fs.cpSync("/tmp/allowed/src/", "/tmp/allowed/dest/", { recursive: true });
console.log("read:", fs.readFileSync("/tmp/allowed/dest/link", "utf8").trim());
'

Output (before fix):

blocked: ERR_ACCESS_DENIED
blocked: ERR_ACCESS_DENIED
read: SECRET

How

Added permission checks using env->permission()->is_granted() for both kFileSystemRead and kFileSystemWrite on the resolved symlink target before:

• create_symlink() call (line ~3819)
• create_directory_symlink() call (line ~3822)
• copy_symlink() call in the verbatimSymlinks path (line ~3754)

Test

Added test/parallel/test-fs-cp-permission-symlink.js which verifies that fs.cpSync throws ERR_ACCESS_DENIED when copying a directory containing a symlink pointing outside the allowed permission paths.

Fixes: #63179
Refs: CVE-2025-55130

[RafaelGSS]

this change is not required

[RafaelGSS]

Suggested change

	// Permission check for verbatimSymlinks path (incomplete
	// CVE-2025-55130 fix)
	// Permission check for verbatimSymlinks path

It's not an incomplete fix, it's not a vulnerability, I told you.

[RafaelGSS]

We shouldn't resolve the path and then perform the check, this goes against permission model behavior, we never call a fs syscall to check if we can in-fact read/write to a file, this is controversial (that's why symlinks aren't supported)

[fg0x0]

Thanks for the review. I'll drop the whitespace change and remove the CVE reference from the comments.

On the design point - understood. The permission model avoids fs syscalls for validation by design, and resolving the symlink target before checking breaks that principle. I see why symlinks are intentionally unsupported.

Would a documentation-only approach be more appropriate here? Something like a note in the permission model docs that symlinks in copied directories can reference paths outside the allowed scope, so users relying on --allow-fs-read/write boundaries should be aware of this behavior.

Or if you'd prefer I just close the PR, that's fine too.

[RafaelGSS]

Would a documentation-only approach be more appropriate here? Something like a note in the permission model docs that symlinks in copied directories can reference paths outside the allowed scope, so users relying on --allow-fs-read/write boundaries should be aware of this behavior.

Or if you'd prefer I just close the PR, that's fine too.

We do have documentation for that, but perhaps that's not clear. Happy to review any updates on it :)