-
-
Notifications
You must be signed in to change notification settings - Fork 502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DietPi-Software | Node-RED: Run under nodered? #1294
Comments
Hi,
Nice, thanks. We are excited. |
8.0 This install was only done a few days ago. |
Thanks for the information, confirmed we currently use |
I Have two installations where I use node-red my main NAS server and a Kodi box. It was a simple task to add a node-red user and setup sudo on my NAS. However it can be very convenient to have node-red running under root as it does on my Kodi box where I use it to shutdown and reboot the system. I would suggest having an option to have node-red run under either it's own user or root |
@DarkElvenAngel , you do not need to run Node red as root to do this, but you do need to learn how to use sudoers. |
@TerryE your exactly right I don't need to run as root I just never bothered to set my Kodi box to run as it's own user |
@Fourdee I have already set up and run node-red as it's own user would there be a good place to post my setup? |
Thanks for the offer, by all means post if you are willing to share 👍 |
I'm attaching my setup for node-red that runs under it's own user. UPDATED
Next edit the /etc/systemd/system/node-red.service change the User=root to User=node-red
Created a user and group for node-red Give the user node-red the ability to write to the it directory
Since we have change the service run Then we start node-red service with Now node-red is running under the node-red user If you want node-red to run commands with sudo we run NOTES: |
@TerryE for your application you can try using the www-data user but I haven't tested that. I know this setup works been running for 8+ months |
@DarkElvenAngel, as a general principle you should use separate service accounts for separate services. That way you have the option of using UID / GID-based access control to isolate web apps from Node RED ones, etc. Such dynamically allocated service accounts are usually allocated in the 100-499 range(1), not 55 as you have used. 😄 |
@TerryE I choose 55 because I need a static UID that is available on all nodes on the network. 55 is not used. On FreeBSD, porters who need a UID for their package can pick a free one from the range 50 to 999 and then register the static allocation. |
Sorry, I didn't realise that you used BSD, Even so, if you want this to apply this over other *nix platforms then it makes sense also to comply with the Linux Standard Base Core Specification. |
@TerryE so I will update to UID:gid 155:155 and that should satisfy all requirements, yes? I've update my setup post. Thanks for the insight. |
@Fourdee perhaps you can unlock #1297 so I can respond in the correct issue. Re logs, the services still log to the RAMdisk |
@Fourdee Dan, BTW I think that the title is wrong: it should be Run nodered under its own service account. There are good reasons why this should be separate from @DarkElvenAngel, you typically don't statically allocated service account UIDs. I created my version by adduser --system --group --no-create-home --shell=/bin/nologin nodered |
+ DietPi-Software | NodeRed: Corrected user which nodered runs under, now runs as its own user, created during install: https://github.com/Fourdee/DietPi/issues/1294#issuecomment-354314318
NodeRed will run under user |
Required Information:
Additional Information (if applicable):
Expected behaviour:
Node red is intended to be run from an unprivileged service account (much in the same way that Apache2 uses typically
www-data
), and hence node red flow developers do not have direct access to root services. Linux provides standard sandboxing patterns (e.g. using/etc/sudoers
) if specific privileged functions need to be made accessible to flows.Actual behaviour:
Node-red runs as root, and this means that any flow has full root access to the processor.
Steps to reproduce:
Construct a minimal flow
timestamp
->exec
->debug
with the exec script asps -u
and you get aps -u root
listing. Alternatively replace this by ashutdown -H now
to get a better idea of the vunlerability.Did you submit a
dietpi-bugreport
?No, not for this one.
Extra details:
I will post my suggested workaround here when done.
The text was updated successfully, but these errors were encountered: