Hello there,
I gifted myself a Raspberry Pi 4 for Christmas in order to set it up with all the wonderful home automation and IoT stuff like NodeRED, mqtt, influxDB, grafana, etc. This shall actually not only be a test setup, but should then automate some stuff in my home.
And now I am wondering how to best setup NodeRED. From the documentation section I learned that you can set it up as a local install or run it in Docker. In the forum I also found the way of a global install, which was not really recommended.
My plan is, to go for the local installation. An now comes the question: Under which user should I install NodeRED preferably? I replaced the standard user pi with a personal user with sudoprivileges. But should I install NodeRED under this user or should I create a separate nodered-user as described here: https://wiki.instar.com/Software/Linux/Node-RED/
Does any method has advantages regarding security or does it not even matter? What about the later connection to mqtt, influxdb, etc?
@bakman2 thanks for the reply. I found this script already. And actually its content got me thinking, which user to use. Before looking into the content, I was assuming that nodered will be globally installed. But apparently it is user specific.
So the question remains: Does it make any difference under which user I install NodeRED?
Node-red is installed as service and will request your password when installing (ie sudo). Long story short: no it should not matter, but as root is not recommended.
Node red itself will be installed globally, but the systemd script installed will run it as the user who ran the script, and will expect the flow files etc to be in that users ~/.node-red directory. Node red will have access to that users files. Apart from that it doesn't make much difference which user you choose. It is not advisable to run node-red as root as then node-red would have access to the whole file system and a flow could, accidentally or maliciously, trash the system or access files it should not have access to.
Thank you for the explanation. Exactly this is holding me back. I am not planning to install NodeRED as root, so it would not have access to the whole file system. But as described, it can access the files of my user account. And I do not want a program, which is accessible via a browser from the outside, to be able to mess around with them, as they also include private key files for ssh access to other machines (mainly for git access).
So to me it sounds like it would be wiser to create a separate "nodered" user account and run the installation script under this account. Then the systemd script will start NodeRED under this account.
@zenofmud thanks for the advice. I will do this for sure. But it depends on the definition of "outside", which was ambiguous in my post. I meant from outside the Pi and not yet from outside my network via the web.
So to me it sounds like it would be wiser to create a separate "nodered" user account and run the installation script under this account. Then the systemd script will start NodeRED under this account.
No, it will still receive root permissions as it lives in /usr/bin, just like any other program that needs to run.
And I do not want a program, which is accessible via a browser from the outside, to be able to mess around with them
The browser cannot access them, the point of a browser is the sandbox, it cannot access local server filesystems.
I believe that is not correct. The systemd script provided by the node red install script runs node red as the user that ran the script. Therefore node red has the permissions of that user. Where node red is installed to is irrelevant. What matters is the permissions of the user running the script. This is no different to any program. For example the command rm is installed into /bin but if a normal user attempts to use rm to delete system files it will fail with a permissions error.
[Edit] Further to this:
The browser can initiate actions in node-red (running in the server), those actions may or may not be permitted, dependent on the permissions of the user running node-red.
Hi Gunter, my personal view is that you are sensible to install NR locally. That's what I always do.
I created a small script to help with local installs,
But it only helps with the actual Node-RED install, it isn't comprehensive like Dave's Pi script. So you need to have installed Node.js correctly before trying it. Create your user, install my package globally and then use the script to create the folders and install Node-RED. In the alt. installer, you will find a systemd script that you can adapt if you want to have Node-RED running as a service like the standard install does. Don't forget to change the user as needed & check the startup dependencies are what you want.
Close but I'm not sure totally true. There is, as I understand things, a small possibility of a permissions leakage because the app itself is owned as root - how realistic a risk this is in indeterminate I think since I'm not sure that anyone has done a detailed security analysis.
This is the main risk certainly.
A good example. But remember that these apps do get regularly updated as security flaws are discovered so it isn't a zero risk. Just a very small one.
Security itself isn't the only reason for not installing Node-RED globally. Installing and updating as a non-admin user is safer in general & isolating server code to a specific user is also good practice as it helps restrict and sideways movement that might be made possible if an attacker breaks free of the sanbox.
But also, it allows you to do backup/restore more easily and to run different NR instances on different versions of NR.
Personally, I find this a much easier way to manage Node-RED.
I think there may be some confusion over the term "installing node-red as root". Node-red is an npm module, not actually a program in the normal sense. The program that actually runs is node.js and it invokes node-red. Npm modules may be installed globallly (which requires root permissions, and node red is installed somewhere like /usr/lib) or locally in which case it resides within the current users home directory. An advantage of install locally is that multiple versions of node-red can be installed at the same time. An advantage of installing globally is that it is available to any user. None of this affects the permissions that node-red has at run time, which are determined by the permissions of the user running node red.
The install script provided for Debian based systems such as Ubuntu and Raspbian (see here) installs node-red globally. Some prefer to install it locally. The advantage of the pi script is that it does everything for you. If you don't wish to install multiple versions of node red then I recommend using the pi script.
Thanks for the various explanations, @Colin and @TotallyInformation. The alternate installer is now again a new option. I start to get confused
I just checked the script once more. Indeed it installs NodeRED for all users, when the GLOBAL-Flag ist true, which it is by default. However, further down in the script, global nodes are then installed locally in the user-directory instead. So in the end, NodeRED itself can be accessed by all users, but not the nodes. Or did I miss something?
This seems to be the hairy part for me. Maybe I should read more into the node.js and npm topic to understand better what actually is going on.
Or maybe I just give it a try now and learn on the way
I believe there is some historical stuff in there. I think originally some of the nodes that might be considered optional were actually required by node-red, so they had to be installed globally along with node-red itself. Node red was then changed so that these nodes were no longer required in all circumstances so there is code in the script to cope with updating earlier installations, moving these nodes from global to local. For a new installation, nodes that are absolutely required for node-red to run are installed globally and any optional nodes are installed locally for that user. If a different user wanted to use node red then he/she would have to manually install those nodes if he wanted to use them.
Yep, just go for it. You can always change your mind later. It would not be a big deal to change an install from global to local.
It is only a helper, you don't need it. All it does is standardise some settings really and makes sure that I do things consistently. If you read through the script, you will see what it does.
You mentioned doing local installs and the script simply does that in a consistent way that I find useful.
Install NR into a chosen master folder
Create a custom userDir folder within the master folder
Creates a master package.json file and another in the userDir folder with standard npm scripts for starting things, updating them and so on.
Makes sure that you have a valid settings.js file
Provides a template systemd startup script.
All things you could easily do yourself.
Often the best way with things like this
Another advantage of doing a local installation using the alt. installer is that you can remove everything simply by deleting your master folder. Create as many as you like of course, they are all entirely independent of each other which is ideal for playing and learning.
I often have multiple versions of NR set up on my dev PC along with clean versions for testing things and so on.
You can do multiple instances with a standard installation but they all have to be the same version. Also, I find it much easier to manage the settings and configuration independently with local installations.
So Node-RED is installed with the official script under a separate user. Let's see where this takes me.
I had not even started installing Node-RED, when I already regretted creating the new user, because I had to copy some of my dotfiles (.zshrc, .vimrc,...) to this user to actually be able to work with it .
That's a reasonable approach though a user dedicated to just running Node-RED is "best" overall just as you would have a separate user for running a web server or indeed most other servers under Linux.
Personally, I do almost all my Linux admin from a Windows PC and there are various ways to make that easy without having to faff with the settings for the Linux users. I don't do enough Linux command line stuff regularly enough to be fluent.
.