Version
v26.7.0
Platform
Linux localhostage 7.0.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:52:35 UTC 2026 x86_64 GNU/Linux
Subsystem
permission model
What steps will reproduce the bug?
p_a_repro.js
p_a_run.sh
====================================================
Running p_a_repro.js normally
>dlopen> /path/to/any.node: cannot open shared object file: No such file or directory
====================================================
Running p_a_repro.js with permission
[AUDIT] node:permission-model:fs: FileSystemRead /etc/hosts
>lstat> Access to this API has been restricted
[AUDIT] node:permission-model:fs: FileSystemRead /etc/hosts
>stat> Access to this API has been restricted. Use --allow-fs-read to manage permissions.
[AUDIT] node:permission-model:fs: FileSystem
>symlink> fs.symlink API requires full fs.read and fs.write permissions.
>dlopen> Cannot load native addon because loading addons is disabled.
====================================================
Running p_a_repro.js with permission-audit
[AUDIT] node:permission-model:fs: FileSystemRead /etc/hosts
>lstat> Access to this API has been restricted
[AUDIT] node:permission-model:fs: FileSystemRead /etc/hosts
[AUDIT] node:permission-model:fs: FileSystem
>symlink> fs.symlink API requires full fs.read and fs.write permissions.
>dlopen> Cannot load native addon because loading addons is disabled.
====================================================
Running p_a_repro.js with permission-audit with allow
>dlopen> /path/to/any.node: cannot open shared object file: No such file or directory
(node:61707) [PERM0001] SecurityWarning: The flag --allow-addons must be used with extreme caution. It could invalidate the permission model.
(Use `node --trace-warnings ...` to show where the warning was created)
How often does it reproduce? Is there a required condition?
always
What is the expected behavior? Why is that the expected behavior?
Audit mode aka --permission-audit is documented as:
The --permission-audit flag enables audit mode for the Permission Model. In audit mode, permission checks are performed but access is not denied — no ERR_ACCESS_DENIED error is thrown. Instead, each permission violation is published through the node:diagnostics_channel module, allowing the application to observe and log which operations would be denied under enforce mode. Execution continues normally.
The Running p_a_repro.js normally and Running p_a_repro.js with permission-audit should have the same outcomes/errors
What do you see instead?
--permission-audit is enough to trigger some permission enforcement - namely on lstat, symlink and dlopen
Additional information
I'm interested in contributing a fix. Might need some pointers.
Version
v26.7.0
Platform
Subsystem
permission model
What steps will reproduce the bug?
p_a_repro.js
p_a_run.sh
How often does it reproduce? Is there a required condition?
always
What is the expected behavior? Why is that the expected behavior?
Audit mode aka
--permission-auditis documented as:The
Running p_a_repro.js normallyandRunning p_a_repro.js with permission-auditshould have the same outcomes/errorsWhat do you see instead?
--permission-auditis enough to trigger some permission enforcement - namely on lstat, symlink and dlopenAdditional information
I'm interested in contributing a fix. Might need some pointers.