Source Code: src/permission.cc
\nPermissions can be used to control what system resources the\nNode.js process has access to or what actions the process can take\nwith those resources.
\nThe permission model implements a \"seat belt\" approach, which prevents trusted\ncode from unintentionally changing files or using resources that access has\nnot explicitly been granted to. It does not provide security guarantees in the\npresence of malicious code. Malicious code can bypass the permission model and\nexecute arbitrary code without the restrictions imposed by the permission\nmodel.
\nIf you find a potential security vulnerability, please refer to our\nSecurity Policy.
", "modules": [ { "textRaw": "Process-based permissions", "name": "process-based_permissions", "modules": [ { "textRaw": "Permission Model", "name": "permission_model", "meta": { "added": [ "v20.0.0" ], "changes": [ { "version": [ "v23.5.0", "v22.13.0" ], "pr-url": "https://github.com/nodejs/node/pull/56201", "description": "This feature is no longer experimental." } ] }, "stability": 2, "stabilityText": "Stable", "desc": "The Node.js Permission Model is a mechanism for restricting access to specific\nresources during execution.\nThe API exists behind a flag --permission which when enabled,\nwill restrict access to all available permissions.
The available permissions are documented by the --permission\nflag.
When starting Node.js with --permission,\nthe ability to access the file system through the fs module, spawn processes,\nuse node:worker_threads, use native addons, use WASI, and enable the runtime inspector\nwill be restricted.
$ node --permission index.js\n\nError: Access to this API has been restricted\n at node:internal/main/run_main_module:23:47 {\n code: 'ERR_ACCESS_DENIED',\n permission: 'FileSystemRead',\n resource: '/home/user/index.js'\n}\nAllowing access to spawning a process and creating worker threads can be done\nusing the --allow-child-process and --allow-worker respectively.
To allow native addons when using permission model, use the --allow-addons\nflag. For WASI, use the --allow-wasi flag.
When enabling the Permission Model through the --permission\nflag a new property permission is added to the process object.\nThis property contains one function:
API call to check permissions at runtime (permission.has())
process.permission.has('fs.write'); // true\nprocess.permission.has('fs.write', '/home/rafaelgss/protected-folder'); // true\n\nprocess.permission.has('fs.read'); // true\nprocess.permission.has('fs.read', '/home/rafaelgss/protected-folder'); // false\nThe Permission Model, by default, restricts access to the file system through the node:fs module.\nIt does not guarantee that users will not be able to access the file system through other means,\nsuch as through the node:sqlite module.
To allow access to the file system, use the --allow-fs-read and\n--allow-fs-write flags:
$ node --permission --allow-fs-read=* --allow-fs-write=* index.js\nHello world!\nThe valid arguments for both flags are:
\n* - To allow all FileSystemRead or FileSystemWrite operations,\nrespectively.,) to allow only matching FileSystemRead or\nFileSystemWrite operations, respectively.Example:
\n--allow-fs-read=* - It will allow all FileSystemRead operations.--allow-fs-write=* - It will allow all FileSystemWrite operations.--allow-fs-write=/tmp/ - It will allow FileSystemWrite access to the /tmp/\nfolder.--allow-fs-read=/tmp/ --allow-fs-read=/home/.gitignore - It allows FileSystemRead access\nto the /tmp/ folder and the /home/.gitignore path.Wildcards are supported too:
\n--allow-fs-read=/home/test* will allow read access to everything\nthat matches the wildcard. e.g: /home/test/file1 or /home/test2After passing a wildcard character (*) all subsequent characters will\nbe ignored. For example: /home/*.js will work similar to /home/*.
When the permission model is initialized, it will automatically add a wildcard\n(*) if the specified directory exists. For example, if /home/test/files\nexists, it will be treated as /home/test/files/*. However, if the directory\ndoes not exist, the wildcard will not be added, and access will be limited to\n/home/test/files. If you want to allow access to a folder that does not exist\nyet, make sure to explicitly include the wildcard:\n/my-path/folder-do-not-exist/*.
If you're using npx to execute a Node.js script, you can enable the\nPermission Model by passing the --node-options flag. For example:
npx --node-options=\"--permission\" package-name\nThis sets the NODE_OPTIONS environment variable for all Node.js processes\nspawned by npx, without affecting the npx process itself.
FileSystemRead Error with npx
The above command will likely throw a FileSystemRead invalid access error\nbecause Node.js requires file system read access to locate and execute the\npackage. To avoid this:
Using a Globally Installed Package\nGrant read access to the global node_modules directory by running:
npx --node-options=\"--permission --allow-fs-read=$(npm prefix -g)\" package-name\nUsing the npx Cache\nIf you are installing the package temporarily or relying on the npx cache,\ngrant read access to the npm cache directory:
npx --node-options=\"--permission --allow-fs-read=$(npm config get cache)\" package-name\nAny arguments you would normally pass to node (e.g., --allow-* flags) can\nalso be passed through the --node-options flag. This flexibility makes it\neasy to configure permissions as needed when using npx.
There are constraints you need to know before using this system:
\n--env-file or --openssl-config are designed\nto read files before environment initialization. As a result, such flags are\nnot subject to the rules of the Permission Model. The same applies for V8\nflags that can be set via runtime through v8.setFlagsFromString.node:fs module bypasses the\nPermission Model.