Let me explain what I am trying to achieve, then perhaps you may choose to be a bit more helpful?
I am tyring to use the Exec node to run the following command to update NR:
npm install -g --unsafe-perm node-red
But of course it fails, as the user node-red does not have access to /etc and its subdirectories.
I know there's plenty alternative ways to update NR, that's not my point. I'm using this as an exercise to learn. You are most welcome to contribute to my learning.
Sorry, I misunderstood, I thought you wanted access to directories outside the container. I am afraid I have no idea how you can do that from node red inside Docker. Docker isn't normally used like that. This page includes details on the usual way of updating the node red version in Docker. https://nodered.org/docs/getting-started/docker.
I don't know why I continously fail to make myself clear : I'm not trying to update NR. I know how to do that.
I'm just using the update command as an example in order to learn how to handle (achieve) access rights.
So please do not tell me how to update NR, tell me how to obtain elevated privileges for the user account node-red
To be fair, @oywino, this post makes it sound pretty much like you are trying to upgrade Node-RED within the docker container. It isn't clear that you are using that as an example of a command to run and your actual goal is to run things with root access.
I don't know how familiar you are with linux in general, so my apologies if you already know this and have tried it, but you would use the sudo command to run a command with more privileges than your current user. For example:
sudo npm install -g --unsafe-perm node-red
That would normally prompt you for your user password, but you can config it to allow your user to run certain commands with sudo, without having to enter your password by editing the sudoers file. Does that give you enough to go read up on sudo and see where it gets you?
Can you clarify whether you are trying to do things within the container that need elevated rights, or you want to run things outside the container (such as writing to /etc in the main file system of the machine).
That's ok (even I make mistakes)
As far as I know - since apt-get isn't available either, there's no easy way to get sudo installed. I was wondering about chown but I'm no Linux CLI expert.
All I want is to figure out how to give user node-red write access to /etc (recursively) inside the container.
As the saying goes. “If you are trying to get there I wouldn’t start from here”. We use a two stage build to create the container. So we build it then strip out bits that aren’t normally needed to save space. Like all the build tools, apt, etc.
If you want to do want you want to do you would be better building your own container from scratch.
Well, I appreciate your advice, but to me it sounds like; "If I need another door between the kitchen and my living room, it's better to burn down the whole house and build a new house from scratch - with the desired number of doors (?)"
That sounds like overkill from my perspective.
There must be an easier way to control access rights (even though neither of us seem to know how).
Perhaps someone else knows, who happen to read this post?
You can keep asking and maybe someone else will have a different answer to the people who actually created and maintain the container.
The container has been built to run Node-RED. That is it's primary purpose. To do that does not require write access to /etc. If you can describe why you need that level of access, it may be easier to suggest something.
Your house analogy isn't really appropriate.
We provide a default house. We also provide the tools for you to easily build you own house with whatever custom features you want.
In most cases, the default house is all that's needed. But at some point, adding one line to the dockerfile and building your own is going to be far easier.
Please don't misunderstand me - I do really appreciate your assistance, And I agree with your logic.
I can see where you are going by questioning my objectives. Let me put it this way; The whole thing began when I stumbled across this post:
And quickly discovered that the "project" failed when NR was installed as a container. Then I began investigating why (again - just for the learning experience).
I did post my question in that thread too - but with no response.
I still have a distinct feeling that there must be an easy way around this issue. Perhaps by adding user node-red to the root group during deployment (or something like that).
Here below the contents of my node-red dockerfile which installs sudo.
######### Changing to root as below commands should be run as root #############
# Following command installs node-red-admin which is needed if you want to create a hashed password
# for the node-red editor. For that run command "node-red-admin hash-pw" in a terminal window
# for the node-red service in the BalenaCloud dashboard.
RUN npm install -g --unsafe-perm node-red-admin
# installing sudo command
RUN set -ex && apk --no-cache add sudo sqlite
# following commands should assure that user node-red can use sudo without requiring to enter a password.
RUN echo "node-red ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
######### Changing back to node-red user #####################
#RUN npm install --unsafe-perm node-red-node-sqlite
COPY settings.js entrypoint.sh ./
# the below entrypoint replaces the entrypoint of the nodered/node-red
ENTRYPOINT ["bash", "entrypoint.sh"]
Hang on - so are you saying that you want the instance of NR running in the container to have additional privileges on the host it is running on.
If that is the case this is usually handled by passing in the UUID and GUID that it will map to on the host system.
You would have to look at the docker build script to see if there are options that are accepted - and if they are not you could fork of a seperate build and update the docker compose process to accept these.
I suppose you could try (although i never have) to pass in the root user and group IDs - i usually create a Linux user with the privileges where i want and then use that to run the specific container.