User inside the container

[cairoapcampos]

Details

Describe the solution you'd like: A non-root user can be used when the container is started.

Anything else you would like to add:

Additional Information: Using a user other than root seems to be safer.

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[pirhoo]

This is how I did it, at the end of my Dockerfile

ADD ./entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER dev # Use whatever you want
ENTRYPOINT ["/entrypoint.sh"]

My entrypoint.sh is as simple as:

#!/bin/bash
set -e

# Check the current user isnt root
if [ "$EUID" -ne 0 ]
then
  sudo /sbin/my_init
else
  /sbin/my_init
fi

I tried several things with /sbin/setuser but it didn't work. Let me know if you think it's a bad idea! I know they have been many discussions about running this image as non-root users. This is the only solution I found so far to do it.

[cairoapcampos]

I will test your solution. Thanks.

[HydroMoon]

I would love to know your finding guys for setting a non root users.

Thanks

[punowo]

This is how I did it, at the end of my Dockerfile

ADD ./entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER dev # Use whatever you want
ENTRYPOINT ["/entrypoint.sh"]

My entrypoint.sh is as simple as:

#!/bin/bash
set -e

# Check the current user isnt root
if [ "$EUID" -ne 0 ]
then
  sudo /sbin/my_init
else
  /sbin/my_init
fi

I tried several things with /sbin/setuser but it didn't work. Let me know if you think it's a bad idea! I know they have been many discussions about running this image as non-root users. This is the only solution I found so far to do it.

Sorry, will this also work on older versions like bionic ?

[samip5]

This is how I did it, at the end of my Dockerfile

ADD ./entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER dev # Use whatever you want
ENTRYPOINT ["/entrypoint.sh"]

My entrypoint.sh is as simple as:

#!/bin/bash
set -e

# Check the current user isnt root
if [ "$EUID" -ne 0 ]
then
  sudo /sbin/my_init
else
  /sbin/my_init
fi

I tried several things with /sbin/setuser but it didn't work. Let me know if you think it's a bad idea! I know they have been many discussions about running this image as non-root users. This is the only solution I found so far to do it.

Sorry, will this also work on older versions like bionic ?

There should be no reason why it wouldn't work to my knowledge.

[punowo]

This is how I did it, at the end of my Dockerfile

ADD ./entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER dev # Use whatever you want
ENTRYPOINT ["/entrypoint.sh"]

My entrypoint.sh is as simple as:

#!/bin/bash
set -e

# Check the current user isnt root
if [ "$EUID" -ne 0 ]
then
  sudo /sbin/my_init
else
  /sbin/my_init
fi

I tried several things with /sbin/setuser but it didn't work. Let me know if you think it's a bad idea! I know they have been many discussions about running this image as non-root users. This is the only solution I found so far to do it.

Sorry, will this also work on older versions like bionic ?

There should be no reason why it wouldn't work to my knowledge.

Sorry I do not know what I was doing wrong. It works.

[adamacosta]

Having a non-root user that runs the supervisor process as root using sudo sort of defeats the purpose of having a container not run as root. The service manager is still going to run as root in this scenario, even though the container's process it spawns from doesn't. Frankly, I don't even see how it makes sense for sudo to exist in a container.

I've been having to figure out how to run Overleaf in a military environment that requires all containers to actually not run as root unless they're cluster administration services running in a system namespace, and it required a few steps:

• Create a suitable user and group
• User needs to be in docker_env group to write to the container environment or set +aw on /etc/container_environment
• Remove any /sbin/setuser directives from all of the services runit is supervising
• chown everything in /etc/runit to the container user or +aw to let it run as an arbitrary user

Some of this probably defeats the purpose of this base image existing, but makes it more usable in Kubernetes, where the standard has become using sidecar containers for the kinds of system administration tasks runit accomplishes. I can't speak to how this is typically done in Docker. This involves turning off sshd, cron, logrotate, syslog, if they're otherwise enabled, and figuring out everywhere this container tries to write a log and making those symlinks to /dev/stdout or /dev/stderr.

[bytestream]

One problem with using sudo to start my_init is it doesn't reap zombie processes. #299 (comment)