Open mirekphd opened 6 years ago
@mirekphd Yes, it certainly is possible. Please set the env var USERID
when running your image, as described in the documentation https://www.rocker-project.org/use/managing_users/
We should probably support doing this with -u
too, the options supported there have evolved quite a bit since we adopted the USERID
convention in very early versions of Docker and we'll probably need to keep that for backwards compatibility. PR's welcome, note that the current user config is handled by https://github.com/rocker-org/rocker-versioned/blob/master/rstudio/userconf.sh
@cboettig This works, but only in docker. It would be a security hole if one could set an arbitrary user ID by means of an environmental variable, which is why OpenShift will not allow it. We still cannot bypass the requirement of setting user ID properly, using OpenShift's "runAsUser" (which must also come from a pre-defined range over which local node admins and devs have no control). This is executed using docker run -u switch, which raises the above-mentioned error.
So the proposed solution:
docker run -it -p 8787:8787 -e USERID=1234 rocker/rstudio
... while it sets uid and gid to 1234 under docker, will not be reproducible under OpenShift, because OpenShift always uses the -u switch to control user IDs. So assuming we set runAsUser to a security-policy-approved value of 3456 and passed env variable USERID set to 1234, OpenShift will execute:
docker run -it -p 8787:8787 -e USERID=1234 -u 3456 rocker/rstudio
but this being an attempt to set -u different from 0 (here: to 3456) will in case of rocker/rstudio result in: "
s6-mkdir: warning: unable to mkdir /var/run/s6: Permission denied
@mirekphd Thanks for explaining the context of your use case a bit more. I'm not familiar with OpenShift so not aware of this constraint that containers run as a random non-root user.
As I mentioned, I agree it makes sense to support the -u
flag, it's just not obvious to me what the best way to implement this is. As I mentioned, a Pull Request would be more than welcome. I appreciate the links to the Jupyter example but it's not entirely obvious to me from that.
As you probably know, the RStudio image runs as root, which executes the RStudio server daemon. Non-root users log in to the resulting rsession this spawns, but RStudio server supports multiple users, and it's not obvious to me how to change things so that the container can be run by a non-root user and still successfully launch the RStudio server. (I know that some projects, e.g. binder, by-pass RStudio's server and execute rsession directly, thus supporting only a single user model, but that would be a significant breaking change and no longer be providing rstudio server part).
So, suggestions or PRs welcome. I appreciate that the Jupyter script handles the problem about a configuring things to accommodate this case where a random user is generated a runtime and unknown at build time, but this still leaves us with the more fundamental problem of running the container as a non-root user. (Perhaps we should change the issue title, from Cannot run with aribtrary user ID
, which is not the case generally, to something more specific, like Cannot run rstudio container default command as non-root user
, which is appears to be what OpenShift is insisting upon).
I had the same problem with another docker container using s6 and found the following repository which already has a fix for it.
https://github.com/untoreh/containers/commit/fd6355b5e34eb0ef29522306b5becc25719e31c4 https://github.com/untoreh/containers/blob/master/openshift/alpbase/cont-init.d/uid_entrypoint
I hope it will also help you.
And the /etc/password editing script added to entry point (where the final UID is known) comes verbatim straight from the OpenShift documentation: https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html#openshift-specific-guidelines (see Support Arbitrary User IDs). Make sure you delete the existing rstudio entry first @cboettig
@sapkra @mirekphd thanks, this sounds promising. I don't have an openshift account to test this though, I'm hesitant to dive in here. Any interest from folks in sending a PR against https://github.com/rocker-org/rocker-versioned/blob/master/rstudio/ setup to adjust the s6 init process to handle this case?
Hi @cboettig I see there have been some changes - I'm looking to get it to run on openshift and have enough resource to try this.
Thanks @BryanHepworth , any updates on this? we'd still be happy for a PR that could address the user id issue for OpenShift without breaking existing behavior.
Hi Carl
I’ve had chance to sort out a few things over the Christmas break, hoping to make progress this month.
Bryan
From: Carl Boettiger notifications@github.com Sent: 02 January 2019 05:50 To: rocker-org/rocker rocker@noreply.github.com Cc: Bryan Hepworth bryan.hepworth@newcastle.ac.uk; Mention mention@noreply.github.com Subject: Re: [rocker-org/rocker] Cannot run with randomly generated user ID (e.g. via OpenShift) (#295)
Thanks @BryanHepworthhttps://github.com/BryanHepworth , any updates on this? we'd still be happy for a PR that could address the user id issue for OpenShift without breaking existing behavior.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/rocker-org/rocker/issues/295#issuecomment-450790751, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIp63dbey-O-xXFUU2a7flJFRL8KUIEUks5u_EiMgaJpZM4VT_18.
Hi, was support for running in Openshift every implemented?
@priggad from the thread it sounds that this is resolved upstream. if not, can you open a new issue in the currently active repo (https://github.com/rocker-org/rocker-versioned2/issues) describing the problem you see and how to reproduce it, linking back here as appropriate?
The image cannot be run with arbitrary user ID (unknown during docker build, possibly random, as enforced by OpenShift's default security policy).
To reproduce set -u switch in docker run to anything other than 0:
Error message:
This certainly is possible - please have a look at jupyter/base-notebook which is run with group 0 (safe) to be able to add the arbitrary user's entry to /etc/passwd at runtime - this magic happens in lines 102-6 of start.sh