Root user or non-root user inside container

[rudijs (Rudi Starcevic)]

Hi,

I have a basic question when running running a Node.js web server in a Docker container.

Is it OK to run the app as user root inside the container?

For example from here: http://docs.docker.com/examples/nodejs_web_app/ the last 3 lines are:

# Install app dependencies
RUN cd /src; npm install

EXPOSE  8080
CMD ["node", "/src/index.js"]

Should I bother with something like this instead:

# Install app dependencies
RUN cd /src; npm install

RUN useradd -c 'Node.js user' -m -d /home/node -s /bin/bash node
RUN chown -R node.node /src
USER node
ENV HOME /home/node

EXPOSE  8080
CMD ["node", "/src/index.js"]

Most examples I’ve read (docs.docker.com, from The Docker Book, google search) don’t alter the user inside the container process.

Is run as root inside the container OK best practise?

It would be nice to get a clear idea of “Yes you should create a non-root user inside container processes” or “No it’s fine as root”.

Thanks!

[rudijs (Rudi Starcevic)]

One issue I’ve come up against is non root processes writing to a docker VOLUME.

There’s are posts out there suggesting workarounds like configuring the same userid between the host and container, though a drawback is non-portability.

When it comes to webapps would love to hear how others are addressing this.

Thanks.

[rudijs (Rudi Starcevic)]

Hi,

I think some good advice is:

The best practice is to combine:

• running your process as non-privileged user within the containers (docker lets you do that easily)
• stripping the container from all the potentially dangerous system capabilities (docker does that automatically)
• running an hardened Linux, with e.g. a grsec-enabled kernel, or with your distro’s security module (SELinux, AppArmor…)

A root user within a LXC container cannot (in theory) escalate to be root on the host machine; but many people believe that it is possible to do so. It is certainly harder to do with Docker containers (thanks to the capability restrictions) but if security is a big concern, you should stack up multiple safety mechanisms.

From: Redirecting to Google Groups

[belette]

Hi Rudi
I noticed as well some messup in permission & owner with Volume between containers and host using a non root user.
I posted a mesage yesterday regarding this and still interesting to get some information!

[Best Practices] Multiple App in containers?

My question under this is I don’t see how to manage data containers when you need to have more than 10GB of files (for example my mails have much more), so I see perfectly the added value of data containers it is very well in architecture point of view but how to increase the size of it without using doing shared directory with the host ?) Many thanks again

[yyolk (Joseph Chiocchi)]

IMO running as root inside a container simplifies things and persists the micro service methodology

That being said there are times when it is necessary to switch the user, which you’ve done.

It’s always situational.

[xuhdev (Hong Xu)]

It’s generally not advisable to use root in a container. If the container is compromised, you can get more issues with root users – the host and the container share the same Linux kernel any way. Root user is easier to be taken advantage to attack the kernel.

[dalanlan]

@rudijs

There’s are posts out there suggesting workarounds like configuring the same userid between the host and container, though a drawback is non-portability.

Where did you catch this, if i may ask?
Is it this posts on SO:docker - Issue when trying to write to a mounted volume from inside a container as a non-root user - Stack Overflow

[jamesgardner]

Could I ask specifically what you mean by “persists the micro service methodology” ?

[jamesgardner]

Have there been any infamous examples of this happening? Been searching around for examples.

[rpural (Robert Nix)]

Actually, I’ve found that, if you can execute commands as root within a container, and that container has write access to any filesystem on the host system, then I can root the host system quite easily. We’re in the process of deciding how to deal with this issue here before we allow docker to run in the general population, and so far, there hasn’t been a suitable workaround. I’m really surprised that docker was designed with such an obvious security flaw.

[gitd]

Since the docker command is already a rooted command its consequences are also rooted. If you can run the command at all then there is a lot of other damage you can do apart from mapping to and then access protected directories through docker.

On a related note, the requirement for docker to be rooted when not using rooted resources is a bit annoying. If you are running docker and not using ports or mapping to rooted volumes then the in container root profile should naturally map to your user account either directly or through some translation, I would think.

…However, I am new here

[colblake]

Hi everyone,

To deal with permissions issues and volumes i use to run docker or docker-compose, when i’m developing, using-u $(id -u):$(id -g).
With that docker will run the container using my local user if it exist or not into the container.
Using this i avoid creating user 1000 inside the container and only used when developing.
Also if other developer who has not the user 1000 could work without permission issues.

The only problem i have found with this is that if i want to use apt or something that requires higher permissions i can’t do sudo to change to root.