Hi,
I use Node-RED in a project where users can create flows and export data from the server to other systems through a specific endpoint (I have created a custom node for this). If I allow the "Write File" and "Read File" nodes, it seems that someone could potentially gain access to the /data folder. This folder contains important files, such as the settings.js file, which I do not want users to read.
How can I secure or restrict file read/write operations in a Docker environment so that users can only access a temporary folder during runtime without being able to read or write to any other files or directories?
Thanks for your answer!
I understand that I can disable the "Write File" and "Read File" nodes as you suggested. However, my goal is not to completely disable them but rather to restrict their access so that they can only read from and write to a specific folder (e.g., /data/tmp) while preventing access to other directories, such as /data/settings.js.
Since I am running Node-RED in a Docker environment, I am looking for a way to enforce this restriction; either through container-level configurations (e.g., volume mounts, permissions) or by modifying the behavior of the file nodes.
Yes, I understood your requirement and I'm saying there is no way to do what you want with the standard nodes and still allow saving of flows to /data or installing new nodes (which go in /data/node_modules).
You can't just bind mount a file to /data/flows.json because Node-RED writes temp copies first, then moves them over the top to help prevent corruption if a crash happens mid write.
The only way is to create a copy of the existing file nodes and modify them to only accept path prefixes you want, because out of the box the file nodes don't support a "Allow list" of paths.
Also worth pointing out that if the user can install arbitrary nodes or use the function node to load arbitrary modules, they can do pretty much anything at all.
The other option is to build a custom Node-RED launcher (embedding) that loads the settings.js from somewhere else.
A better question is what is in the settings.js file you don't want the users to see? Because if you move to a different storage module and a auth plugin it then you should be able to get the point where there are no useful secrets in the settings.js file so it doesn't matter if they see it. This is basically the approach we've taken with FlowFuse.