Docker hub Quick Start instructions not working... rocker/rstudio:latest requires custom password

[mrJeppard]

host OS: Ubuntu 18.04 docker version: Docker version 18.06.1-ce, build e68fc7a image id: b9b8194ca7d9

I'm seeing the quickstart instructions on docker hub start the container and exit immediately. It seems the default username and password for rstudio are no longer set (?). The container runs fine when -e PASSWORD=something is used, but the docs suggest this is not mandatory, and the logs need to be investigated to see the helpful error message. Here's an example:

docker run -d -p 8787:8787 rocker/rstudio
# see the container was started and exited
docker ps -a

# Check the logs for what happened and see the error message 
docker logs <container-id> > log.txt

log.txt:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] add: executing... 
Nothing additional to add
[cont-init.d] add: exited 0.
[cont-init.d] userconf: executing... 

ERROR: You must set a unique PASSWORD first!! e.g. run with:
docker run -e PASSWORD=<YOUR_PASS> -p 8787:8787 rocker/rstudio

[cont-init.d] userconf: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

[cboettig]

Yup, the quickstart docs are outdated (sorry! Will fix) and the error message is correct. You always need to set a custom password now for rstudio. (We found too many examples of people not doing this on publicly discoverable servers)

[r-cheologist]

It should also be noted that PASSWORD=rstudio (aiming to explicitly reconstruct legacy behavior in a context where no external access is possible), does NOT work. Perhaps the error message should explicitly state that rstudio is not accepted as a password? ... cost me a bunch of build cycles ...

[cboettig]

@r-cheologist good point, I'll update the error message and documentation!

Sorry for the breaking change, I realize this is a nuisance in an already-secure environment. Note that I think you can override the new behavior at runtime by modifying the userconf.sh script locally and binding it to /etc/cont-init.d/userconf, e.g. with the runtime flag

-v $(pwd)/userconf.sh:/etc/cont-init.d/userconf

Not elegant but we wanted to make it intentionally hard to use the default password since some users may not be aware when they are running the server in a publicly discoverable environment.

[prusswan]

This issue should be re-opened because it is still happening.. not everyone is savvy enough to use docker logs <container_name> to pull the logs and see the error messages.

(came from https://github.com/rocker-org/rocker/wiki/Using-the-RStudio-image btw)

[eddelbuettel]

On the other hand we now think that overly liberal earlier policy was a bug, and that current behavior is better. So no change planned. Hence not sure I agree to reopen.

Better / clearer documentation is of course always welcome.

[cboettig]

@prusswan thanks for getting in touch, and it looks like you've also updated the wiki, that's awesome.

I agree that the logs are easy to miss if a user runs with -d, and the previous, less-secure default has been written about in lots of places; including blog posts that are not under our control. Having it in the logs is the one place to be sure it shows up regardless of what docs the user has read though.

I've updated the directions in https://www.rocker-project.org as well and the READMEs... We suffer from a bit of a documentation diaspora I'm afraid... Anyway, thanks again.

[dinvlad]

Just wanted to mention another use case, where we use our own auth proxy (with Google OAuth) in front of RStudio, and disable RStudio's native auth using auth-none=1 in rserver.conf. In that case, we don't need to set PASSWORD at all, because the user won't even enter the native login dialog. But the new image still requires us to supply that password. It would be nice if we could disable that (or even better, the current logic that checks for PASSWORD will check if auth-none=1 option is set and disable the check automatically then).

[cboettig]

@dinvlad Checking the auth-none setting first is a great idea! In your setup, how are you updating the rserver.conf? Do you just volume map to overwrite the existing /etc/rstudio/rserver.conf ?

The current behavior is regulated by the userconf.sh script that runs before rsever is brought up, https://github.com/rocker-org/rocker-versioned/blob/master/rstudio/userconf.sh#L16. I think it would be simple enough to add a line checking auth-none value to that script. Want to send a PR? Otherwise I can take a stab at this when I get a chance. Thanks again for the suggestion.

[dinvlad]

Yep, we mount /etc/rstudio/rserver.conf at run time. I can take a look at userconf when we get to it, but that will be a while :)

[cboettig]

Thanks @dinvlad for the suggestion. This is now implemented and Denis' approach may be of interest to others in this thread.

[cboettig]

cc @r-cheologist @mrJeppard @prusswan

Ok, so now default behavior will still require a password, but users can now opt out of this by setting an environmental variable, e.g.

 docker run --rm -p 127.0.0.1:8787:8787 -e DISABLE_AUTH=true rocker/rstudio

Then going to http://127.0.0.1:8787 in your browser, you will be automatically signed in as the rstudio user without being asked for a password. (Note this example explicitly binds to the localhost, 127.0.0.1, and not 0.0.0.0, which could potentially be accessible from an outside client). Obviously, opt out of password protection only if you know things are secured in some other way!

Thanks @dinvlad for suggesting this approach.

[prusswan]

Will that prevent people from following old instructions and get a VM that cannot start properly? I think one way to avoid that is to generate a random password, and show it to them somehow.

On Sat, Sep 15, 2018, 12:31 PM Carl Boettiger notifications@github.com wrote:

cc @r-cheologist https://github.com/r-cheologist @mrJeppard https://github.com/mrJeppard @prusswan https://github.com/prusswan

Ok, so now default behavior will still require a password, but users can now opt out of this by setting an environmental variable, e.g.

docker run --rm -p 127.0.0.1:8787:8787 -e DISABLE_AUTH=true rocker/rstudio

Then going to http://127.0.0.1:8787 in your browser, you will be automatically signed in as the rstudio user without being asked for a password. (Note this example explicitly binds to the localhost, 127.0.0.1, and not 0.0.0.0, which could potentially be accessible from an outside client). Obviously, opt out of password protection only if you know things are secured in some other way!

Thanks @dinvlad https://github.com/dinvlad for suggesting this approach.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rocker-org/rocker/issues/303#issuecomment-421529981, or mute the thread https://github.com/notifications/unsubscribe-auth/AApA4k4huRDUm3nfPLJ94gG35d0R-rP8ks5ubIKVgaJpZM4WM5YE .

[cboettig]

@prusswan Thanks for the follow up. So, providing a custom password has always worked and will continue to work. Opting out this way is a new option. The only thing that used to work but will no longer do so is the option that was insecure by default:

docker run --rm -p 8787:8787 rocker/rstudio

i.e. neither providing a custom password nor opting out of auth. This will throw an error.

We considered having this approach generate a random password and report it to the user, but unfortunately, there's no obvious way to see this information. Echoing a password into the docker logs is considered poor practice (log files may be archived somewhere), and in any event, a user doing docker run -d -p 8787:8787 rocker/rstudio would not see the log message do to the -d flag.

If you have any ideas about how we could better handle the case of a user running docker run -d -p 8787:8787 rocker/rstudio and then wondering why docker didn't start, I'm all ears. Otherwise, I still think we're better off with an error than an insecure-by-default approach.

Thanks!