Install node red using the ubuntu/debian/piOS script, in this case on clean install of Debian 12. Getting errors I have never seen before...
nodered.service: Changing to the requested working directory failed: Permission denied
nodered.service: Failed at step CHDIR spawning /usr/bin/env: Permission denied
Run node-red-start, and it is just looping with the above errors.
In this case installed node red as root... yes wanted it under root, until I can get all the node development I want to do finished, before I focus on non-root scope.
OK... figured it out... for some reason the user= in the unit file was not set to root. I had uninstalled node-red and reinstalled it (as root) and appears the unit file was not updated or changed? Once I set the user= parameter correctly in the unit file for node-red, error gone, mystery solved.
You really should not run node-red as root, doing that means that node-red could easily trash your system as it has full access to the whole system. Either run it as your normal user or create a user specifically for running node-red and give it just the permissions it needs.
This is particularly true if you ever intend to make node-red accessible via the internet.
It is normal for node-red to be installed globally using sudo, but that is nothing to do with the user that is running node-red.
Following up from Colin's comment. Installing AND running as root means that any Node-RED flow has complete control over the server device and over Node-RED itself.
Obviously, that is a very dangerous position to be in considering how powerful Node-RED is.
Yes... as a matter of fact it does expose full control... and that at times is appropriate, say in a lab or design effort. What I find interesting is that the standard install script 'seemed' to be forcing the issue of not installing as root, but allows question to be asked. I will explain...
If I login, say via SSH, as root, the script runs just fine, when you intent to install as root. For the moment please suspend the ever present warnings or qualifications of root context.
However, if you login in as any user but root, then escalate to root via 'su', then run the standard script, the install script does not honor the root install, in fact the path defaults to "/home//.nodered/settings.js", if not in other places, a non-root context is assumed? How else does the unit file end up with user='non root'.. when running in root context? Script not update the unit file as expected in this case? Since I ran the script under 'su' rather than an SSH session as root? Interesting.
Now I have no idea if this is a quirk with using 'su', a bug in the script, or what. I don't recall ever seeing this behavior in the past, but that does not mean it has not been their awaiting to be tripped over or discovered. Maybe no one has ever run the script the exact way I happen to do? Where I ran the in non-root context script, and ran the script again in root context?
Regardless of recommended or not recommended to run as root... that is a user decision not a developer decision. Yes, of course, that means the user has to accept the implications. I think the script presents a reasonable level of warning on using or not using root... but once root is desired, and selected, the expected behavior is root should be completely honored, right? I believe that is the intention.
Oh, one more question. In the script the passphrase is protected, but the passphrase is in plain text in the settings.js file. I maybe the only one, but protecting the passphrase during script execution seems odd when it is not projected in the actual settings.js file? Yes I tend to fat-finger the passphrase at times... so I validate it in the settings.js file. Hence why I asked the question. Would it not be more user friendly to not protect the passphrase entry during script execution? Well at least for those of us that fat-finger it. Another edge case?
As a competent and experienced user of Linux, you are aware that logging in as root is not the same thing as executing su.
So why would you login as a non privileged user, escalate your privileges with su and then install Node-red?
I wonder if sudo su makes a difference to the install experience.
It seems likely that you ended up with inappropriate values of $HOME or $USER for the install process.
There is a section in the script which may be relevant:
# this script assumes that $HOME is the folder of the user that runs node-red
# that $NODERED_USER is the user name and the group name to use when running is the
# primary group of that user
# if this is not correct then edit the lines below
Not sure I understand you. The settings file has a hash of the password.
Do you generate a hash and then type it into settings.js?
It is NEVER appropriate over the Internet - not for ANY REASON. (Saying from a professional cyber stance here). You must always have Internet facing services run under a restricted user account, never under root. No excuses. You don't need to run as root in order to get sufficient device control.
Which also should NEVER be allowed, even if the server isn't connected to the Internet but doubly so if it is.
If you ever get cyber audited, you will fail big-time.
Sorry, no can do. Remember, this is a public forum and other, less experienced people may read this post.
I don't personally use "the script" but I am sure that it uses sudo where elevated rights are required. You shouldn't be using a root login - EVER. And you don't need su. sudo gives a more controlled method. Even Windows now has sudo.
This does happen from time-to-time. And the recommendation is to remove everything and start again without using root. This is precisely because it is very difficult to try and unpick the permissions mess that it makes. Even where it seems to work, it inevitably seems to result in problems later on.
There are reasons that I always recommend that people do not rely on Node-RED's built-in security. The general insecurity of the settings.js file is one of them.
The original purpose of the Node-RED config was to make it easy for beginners to get started. This does not result in a secure configuration by any means. Dave's excellent script tries to add some sensible settings but, on its own, it cannot provide a completely secure configuration.
There are a couple of threads on the Forum about issues with settings.js and some work-arounds. Suffice it to say that it needs some additional protection. Also suffice to say that, where you need a secure configuration in a commercial/enterprise setting, you should be looking to your other security tooling to provide layers of security over and above Node-RED itself.
PS: Please don't take this as professional security advice, if you are using Node-RED in a professional/commercial setting, you should treat it like any other service and get it checked by your own security professionals.
I never said it was appropriate over the internet... I explicitly qualified a lab environment. I also have done security design... we are not talking about full security context but use in a lab, in a development scope, which I also explicitly noted in my discussion. I even noted by use case is an 'edge' case that is not appropriate beyond the use case I qualified.
I also am enterprise engineering, in fact an emerging technology evaluator for 15 years of my 30+ year career. I am not asking you to disable or remove anything... I am pointing out that the user once they decide what is applicable for them they own the situation. Not the developer. The script seems to not consistently honor this position for whatever odd reason the user= parameter/variable in the unit file is NOT SET CORRECTLY when you select 'root' context. I have done 2 installs where selecting root.. the user= parameter/variable is not set to root... why? Don't know I have yet to walk the code...nor should I have to... as just a user of the script.
Moreover, it is not the role of the developer to protect the user from themselves beyond recommendations that are considered best practice... but once that best practice is deemed by the user, to not be applicable, the script should honor that decision... I found the script did something odd that does not seem to honor that decision once made. Be it quirk, bug or whatever, something I also explicitly noted.
I was even careful to note that I AGREE with the design of the script in its positive effort to ensure best practice is encouraged, and deviation is acknowledged. The issue is the script seems to be doing something odd.. once you decide you want to use root... that is the issue... not a greater discussion on if you should nor should use root or not use root, or if you should ignore best practice or not, or even an audit will pass or fail or not... Not if you are facing the internet or not facing the internet. A point I think you missed.
It is true that there are circumstances where the script ends up with an inappropriate path name for the node-red directory.
The community is in your debt for drawing our attention to this failing.
I won't insult your knowledge and experience by suggesting a work-around.
Over my career I have encountered experienced users who made apparently eccentric choices for technology.
Sometimes when I found out more, I understood the wisdom of their choice.
That's why I asked you questions, but you seem reluctant to respond.
I do not see what makes the context of a laboratory immune from the problems caused by overuse of root.
Another edge case?