permission: do not enforce fs and addons in audit mode - #65659
Open
theSnackOverflow wants to merge 1 commit into
Open
permission: do not enforce fs and addons in audit mode#65659theSnackOverflow wants to merge 1 commit into
theSnackOverflow wants to merge 1 commit into
Conversation
Collaborator
|
Review requested:
|
nodejs-github-bot
added
c++
theSnackOverflow
added a commit
to theSnackOverflow/board
that referenced
this pull request
Aug 30, 2026
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #65659 +/- ##
==========================================
+ Coverage 90.03% 90.04% +0.01%
==========================================
Files 754 754
Lines 255744 255752 +8
Branches 48313 48324 +11
==========================================
+ Hits 230252 230295 +43
+ Misses 16622 16600 -22
+ Partials 8870 8857 -13
🚀 New features to boost your workflow:
|
--permission-audit is documented to perform permission checks without denying access, publishing each violation through the diagnostics channel while execution continues. Three code paths still enforced: * fs.lstat() and fs.symlink() are checked in the JavaScript layer, which threw ERR_ACCESS_DENIED without consulting audit mode. The isAuditMode() helper introduced for ffi was never wired into fs. * Addon loading was disabled upfront in Environment setup, so process.dlopen() failed with ERR_DLOPEN_DISABLED before reaching the audit-aware permission check, and no audit event was published. Skip the throw in the JavaScript checks when audit mode is on, keeping the permission.has() call first so the diagnostics channel event is still published. Leave native addons enabled in audit mode while still applying the kAddon scope, so DLOpen() publishes the denial through the channel and continues to the regular loading path. This also covers the worker path, which inherits kNoNativeAddons from the same option. Each fs API carries its own copy of the check in its sync, callback and promise flavour, so the regression test exercises all six call sites, asserting the --permission enforce behaviour as a control. Fixes: nodejs#65419 Refs: nodejs#63047 Assisted-by: claude:opus-5 Signed-off-by: Ji Hoon Kang <ivory.ma9ic@gmail.com>
theSnackOverflow
force-pushed
the
fix-permission-audit-enforce
branch
from
August 30, 2026 07:13
4efc964 to
2bbef4a
Compare
RafaelGSS
approved these changes
Aug 30, 2026
RafaelGSS
added
permission
Member
|
Good catch. Thanks. |
github-actions
Bot
removed
the
request-ci
Collaborator
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
--permission-auditis documented to run permission checks without denyingaccess, but three paths still enforce:
--permission-auditfs.lstat*ERR_ACCESS_DENIEDfs.symlink*ERR_ACCESS_DENIEDprocess.dlopenERR_DLOPEN_DISABLED, no audit event publishedTwo causes, as far as I can tell:
lib/fs.jsandlib/internal/fs/promises.jsdo notconsult audit mode —
isAuditMode()from lib: handle --permission-audit when propagating flags #63047 appears to have been wiredinto
lib/ffi.jsonly.allow_native_addons = false, soDLOpen()rejectsbefore reaching the audit-aware check.
The fix adds
!permission.isAuditMode()to the six JS checks, keepingpermission.has()first so the audit event is still published, and leavesaddon loading enabled in audit mode while still applying the
kAddonscope.I would welcome guidance on one point: the
symlinkrestriction comes fromCVE-2025-55130, which predates audit mode, so this reads to me as an ordering
gap rather than an intentional exception — though I may be missing context.
Glad to split that part out if security-wg would prefer.
Both new tests fail without the fix and assert the
--permissionbehaviour asa control;
parallel/test-permission*and the full suite pass locally.Detailed analysis is in the issue thread.
Prepared with AI assistance; I reproduced, traced, and tested this myself, and
will handle review feedback personally.
@naugtur — apologies for stepping in, as you had mentioned wanting to take
this. Happy to close in favour of your PR, or to work through review together.