René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"permission: process.permission.drop() aborts (SIGABRT) when two --allow-fs-read grants collide at their first wildcard","articleBody":"### Version\n\nv26.12.0\n\n### Platform\n\nWindows 11 x64. The code path is platform independent, so Linux and macOS are expected to behave the same.\n\n### Subsystem\n\npermission\n\n### What steps will reproduce the bug?\n\nTwo `--allow-fs-read` grants whose text is identical up to and including the first `*`, plus any `process.permission.drop()` call, abort the process.\n\n```sh\nmkdir -p /tmp/sig\ncat > /tmp/sig/app.js \u003c\u003c'EOF'\nprocess.permission.drop('fs.read', process.argv[1]);\nconsole.log('survived');\nEOF\n\nnode --permission \\\n  --allow-fs-read='/tmp/sig/*' \\\n  --allow-fs-read='/tmp/sig/*.js' \\\n  /tmp/sig/app.js\n```\n\n### How often does it reproduce? Is there a required condition?\n\nEvery time, given both conditions:\n\n1. two `--allow-fs-read` grants identical up to and including their first `*`, and\n2. any `process.permission.drop('fs.read', ...)` call.\n\nStartup on its own is fine. Measured controls:\n\n| configuration | exit code |\n| --- | --- |\n| two colliding grants, no `drop()` | 0 |\n| two colliding grants + `drop(entrypoint)` | **134** |\n| single grant + `drop(entrypoint)` | 0 |\n| two colliding grants + `drop()` on an unrelated path | 0 |\n| two non-colliding grants + `drop(entrypoint)` | 0 |\n| collision on the `--allow-fs-write` list + `drop('fs.read', ...)` | 0 |\n\nThe last row is consistent with only the dropped scope's tree being replayed. v22.23.3 is unaffected because `process.permission.drop` does not exist on that line.\n\n### What is the expected behavior? Why is that the expected behavior?\n\n`process.permission.drop()` should either drop the requested scope or throw a catchable error. It should not abort the process.\n\nThe grant combination is a reasonable thing to write. The permission documentation encourages wildcard grants and states that characters after a `*` are ignored, so `--allow-fs-read='/tmp/*' --allow-fs-read='/tmp/*.js'` reads as redundant but harmless rather than fatal, and nothing indicates it becomes fatal once the application calls `drop()`.\n\n### What do you see instead?\n\n`SIGABRT`, exit code 134:\n\n```\nAssertion failed: !path_prefix.empty()\n  at src/permission/fs_permission.h:62\n  in node::permission::FSPermission::RadixTree::Node::CreateChild(std::string_view)\n\n----- JavaScript stack trace -----\n1: drop (node:internal/process/permission:66:16)\n2: /tmp/sig/app.js:1:20\n```\n\n`CHECK` is unconditional in release builds, so application code cannot catch this. A process that drops privileges after startup, which is the intended use of the API, terminates.\n\n### Additional information\n\n**Why startup is safe but `drop()` is not.**\n\n`FSPermission::GrantAccess` only inserts a path when `!Lookup(path)`. `/tmp/sig/*.js` is already covered by `/tmp/sig/*`, so the colliding insert never happens while the flags are applied and the tree is built correctly.\n\nCommit 02bae370c (\"permission: keep explicit fs grants when dropping a covering directory\", 2026-10-13) moved the `granted_paths_` `push_back` out of that `!Lookup(path)` branch so every explicit grant is recorded even when covered. `RebuildTree` then replays the whole recorded list unconditionally, so the first `drop()` inserts both colliding grants into a fresh tree and `CreateChild` trips its own `CHECK`. That makes this a regression introduced alongside the grant-retention change rather than longstanding behaviour.\n\n**Where it aborts.**\n\n`Node::CreateChild` reaches `CHECK(!path_prefix.empty())` when the remaining prefix is empty, which happens when the second grant diverges only after a `*` that both grants share. Since `Lookup` never descends into a `wildcard_child`, the subtree being built past the first `*` is unreachable to lookups, so the insert that aborts appears to be doing no useful work.\n\n**Possible directions**, offered as context rather than as a tested patch, since the right choice interacts with how `granted_paths_` is replayed: either skip insertion once a wildcard has been consumed, given that everything after the first `*` is ignored by lookups, or have `CreateChild` return early on an empty `path_prefix` instead of asserting.\n\nI considered whether this belonged in the security process and concluded it does not: it requires in-process application code to call `drop()`, and it does not meet the denial-of-service criteria in the threat model, which require the behaviour to be directly exploitable by an untrusted source without application mistakes. Filing publicly on that basis. Happy to move it if maintainers see it differently.\n\n`process.permission.drop` is documented as Stability 1.1 - Active Development.\n","author":{"url":"https://github.com/itxcrusher","@type":"Person","name":"itxcrusher"},"datePublished":"2026-10-21T14:33:26Z","url":"https://github.com/nodejs/node/issues/66901"}