vfs: load native addons from a mounted file system · nodejs/node@d0535b1 · GitHub
Skip to content

Commit d0535b1

Browse files
pipobscureaduh95
authored andcommitted
vfs: load native addons from a mounted file system
A native addon inside a virtual file system could not be require()d: dlopen() and LoadLibrary() open a shared object by path, and a VFS path has no inode for them to open. Read the addon's bytes from the VFS and load them from a private, self-cleaning image instead, using the smallest on-disk footprint each platform allows: on Linux an anonymous memfd loaded through /proc/self/fd, so the bytes never reach the file system; on other POSIX platforms a file in a 0700 mkdtemp() directory, unlinked right after loading, with the mapping keeping it alive; on Windows a temp file opened FILE_FLAG_DELETE_ON_CLOSE whose handle is held until exit. This is internal. process.dlopen() keeps its documented (module, filename[, flags]) signature and ignores anything further; the bytes are passed to a dlopenBinary() reachable only through the process_methods binding, which the VFS hook calls for VFS paths. Addons on the real file system are untouched and load directly. Signed-off-by: Philipp Dunkel <pip@pipobscure.com> PR-URL: #65680 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: James M Snell <jasnell@gmail.com>
1 parent e3cc0d9 commit d0535b1

12 files changed

Lines changed: 627 additions & 6 deletions

File tree

‎doc/api/cli.md‎

Lines changed: 23 additions & 0 deletions

‎doc/api/vfs.md‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -419,6 +419,12 @@ system, the callers are responsible for avoiding removal or
419419
invalidation of modules in the virtual file system while they are
420420
being loaded.
421421

422+
Native addons (`.node` files) stored in a mounted VFS can be `require()`d as
423+
well. The operating system's dynamic loader cannot open a virtual path, so the
424+
addon's bytes are read from the VFS and loaded from a private, self-cleaning
425+
temporary image instead. Addons on the real file system are unaffected and
426+
load directly.
427+
422428
## Use with Single Executable Applications
423429

424430
When running as a [Single Executable Application][] built with

‎doc/node.1‎

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -166,6 +166,17 @@ process.permission.has('fs.read', 'custom-require.js'); // true
166166
process.permission.has('fs.read', 'custom-require-2.js'); // true
167167
.Ed
168168
.
169+
.It Fl -allow-fs-vfs
170+
When using the Permission Model, a virtual file system cannot be
171+
mounted by default: \fBvfs.mount()\fR throws \fBERR_INVALID_STATE\fR unless the
172+
user explicitly passes the \fB--allow-fs-vfs\fR flag when starting Node.js.
173+
A mounted VFS serves paths that the file system permissions do not describe,
174+
so mounting one is gated on its own flag rather than on \fB--allow-fs-read\fR or
175+
\fB--allow-fs-write\fR.
176+
.Bd -literal
177+
$ node --experimental-vfs --permission --allow-fs-vfs app.js
178+
.Ed
179+
.
169180
.It Fl -allow-fs-write
170181
This flag configures file system write permissions using
171182
the Permission Model.
@@ -2024,6 +2035,8 @@ one is included in the list below.
20242035
.It
20252036
\fB--allow-fs-read\fR
20262037
.It
2038+
\fB--allow-fs-vfs\fR
2039+
.It
20272040
\fB--allow-fs-write\fR
20282041
.It
20292042
\fB--allow-inspector\fR

‎lib/internal/vfs/setup.js‎

Lines changed: 22 additions & 0 deletions

0 commit comments

Comments
 (0)