chown when specifying username in rstudio container

[ProbablePattern]

Customizing the username produces a long-running (more than 15 minutes, have not waited until the end) chown process before the rstudio server is started. This appears to be related to the volumes added to the container. Keeping the default user "rstudio" does not cause a problem. The workaround is obviously to just keep the default user which is fine for local insecure containers. Enabling authentication, adding a password, and changing the username would be ideal for cloud deployment but this will not be feasible if using large volumes.

Docker on WSL2 on Windows 10
Host username is huser
Container username is duser

Setup up cifs volume then run container with both local volume and network volume

docker volume create \
  --driver local \
  --opt type=cifs \
  --opt device=//xxx.xxx.xxx.xxx/Array \
  --opt o=username=huser,password=pswd,uid=1000 \
  --name Array

docker run -d \
    --name Rocker \
    --hostname Rocker \
    --network bridge \
    -e USER=duser \
    -e DISABLE_AUTH=true \
    -p 127.0.0.1:8787:8787 \
    -v /mnt/c/Users/huser/local:/home/duser/local \
    -v Array:/home/duser/array \
    rocker/rstudio:latest

I am relatively new to docker so I apologize if this is a docker problem rather than an image problem.

[eitsupi]

Hi. You seem to be bind-mounting the Windows volumes as well, what if you don't do this?
Because of the generally slow transfer rate between WSL2 and Windows, it is not recommended to bind-mount the Windows file system to the container.
See the Best Practices.
https://docs.docker.com/docker-for-windows/wsl/#best-practices

[ProbablePattern]

Thank you for showing me that @eitsupi. Even completely removing the local Windows volume the problem persists so it is linked to the few TB of data on the cifs volume. I tried mounting the cifs volume within WSL first and then adding the directory to the container as a local volume. This eliminated the need for creating the docker volume beforehand but did not work. Neither mounting before container is created nor mounting after the container is created in WSL resulted in the container having access to the cifs volume. I think this is some problem with permissions but I know that every UID is set to 1000. The cifs volume issue does not seem to be covered in the WSL2 best practices link that you posted but I appreciate the help with the local volume.

[cboettig]

Thanks @ProbablePattern for the report and @eitsupi for the insight on the WSL2 bind mounting.

@ProbablePattern not entirely sure I followed your security concern though in maintaining the rstudio user. You are running with DISABLE_AUTH=true above (and binding only the localhost, 127.0.0.1 instead of 0.0.0.0 which is good), so I assume this is in a local context where the machine is secure, so it seems like the user name is merely aesthetic (as you probably know, permissions in docker mapped to host machine permissions rely only on matching the UID, not the username). In a non-local setting, you would certainly enable password authentication, and/or consider a reverse proxy server that could put your instance behind https and possibly an additional authentication layer. I'm not a security expert, but I imagine having a username that is not the default is a relatively weak contribution additional security beyond having an appropriately strong password....

[ProbablePattern]

Sorry, @cboettig I should be clear. I am not deploying to the cloud like this because I want to get all the settings down first. Here is a modified example of what I would like to do:

docker volume create \
  --driver local \
  --opt type=cifs \
  --opt device=//xxx.xxx.xxx.xxx/Array \
  --opt o=username=huser,password=pswd,uid=1000 \
  --name Array

docker run -d \
    --name Rocker \
    --hostname Rocker \
    --network bridge \
    -e USER=duser \
    -e USERID=1000 \
    -e PASSWORD=supersecretpassword \
    -p 8787:8787 \
    -v Array:/home/duser/array \
    rocker/rstudio:latest

[cboettig]

@ProbablePattern sure thing, that makes sense. Is the cloud host running WS2L on Windows 10? If it is a Linux-based host, you may not encounter any issues (but do let us know).

My 2c though is not to worry about re-mapping the username. For cloud deploy, I do think it's worth considering using a https connection with a reverse proxy like caddy server. This requires you have your own domain name, but is otherwise quite straight forward. I understand rstudio encrypts the user-entered password with client-side javascript, so password authentication over unsecured http ports isn't totally vulnerable, but still https seems like the better choice to me. I'm just an ecologist not a security professional though, so only take that for what it's worth!

[ProbablePattern]

Thank you. I will try getting a dedicated Linux box.

[eitsupi]

This is obviously due to the following code, which has nothing to do with bind mounting to the Windows file system, so even if you were to run it on a normal Linux machine that is not WSL2, the same thing would happen.

rocker-versioned2/scripts/userconf.sh

Lines 61 to 69 in 3456299

	elif [ "$USER" != "rstudio" ]
	then
	## cannot move home folder when it's a shared volume, have to copy and change permissions instead
	cp -r /home/rstudio /home/$USER
	## RENAME the user
	usermod -l $USER -d /home/$USER rstudio
	groupmod -n $USER rstudio
	usermod -a -G staff $USER
	chown -R $USER:$USER /home/$USER

I think the solution is to build an overwritten image that replaces the above script with a script that excludes the chown process.
This script can handle files under /home/user no matter what their ownership is, so you don't need to chown them in this case since they are set to UID1000 in advance.

Or how about not bind-mounting to /home/duser/array, but mount to /array for example?

docker run -d \
    --name Rocker \
    --hostname Rocker \
    --network bridge \
    -e USER=duser \
    -e USERID=1000 \
    -e PASSWORD=supersecretpassword \
    -p 8787:8787 \
    -v Array:/array \
    rocker/rstudio:latest

At first glance, RStudio Server seems to be able to display only files under the home directory, but I think you can open /array by doing like that.

[cboettig]

I agree that lines

rocker-versioned2/scripts/userconf.sh

Lines 61 to 69 in 3456299

	elif [ "$USER" != "rstudio" ]
	then
	## cannot move home folder when it's a shared volume, have to copy and change permissions instead
	cp -r /home/rstudio /home/$USER
	## RENAME the user
	usermod -l $USER -d /home/$USER rstudio
	groupmod -n $USER rstudio
	usermod -a -G staff $USER
	chown -R $USER:$USER /home/$USER

should be re-considered and probably deprecated. Mechanically I think they should run quickly on a linux host unless the volume is very large, but they are also a bit of a hack. I don't recall entirely why we couldn't just do a usermod here to rename the user and avoid copying anything...

[eddelbuettel]

Sounds like the combination of WSL and crufty config may be to blame. From Linux to Linux, I mount via -v outside:inside fairly regularly, but I often do that with simpler images (i.e. not this rstudio one) and there it generally works just fine. I also found just specifying -u 1000:1000 to be quite helpful as I tend to 1000 (== default Ubuntu user) on the outside too.

[ProbablePattern]

This might shed some light on the issue. I tried @eddelbuettel 's suggestion of specifying -u 1000:1000 and the username change did not work. There was still an rstudio user with uid 1000 and no duser. This occurs whether specifying
-e USERID 1000
or not. I can confirm that huser is 1000.

[eddelbuettel]

But I think that is indeed a feature of the RStudio container which needs a user to operate client/server. In the simpler r-base no such thing:

edd@rob:~$ docker run --rm -ti -u 1000:1000 -v$PWD:/mnt r-base bash
docker@8a1ebb4700ae:/$ whoami
docker
docker@8a1ebb4700ae:/$ touch /mnt/DontTouchThis
docker@8a1ebb4700ae:/$ 
exit
edd@rob:~$ ls -l DontTouchThis 
-rw-r--r-- 1 edd edd 0 Jul  1 14:36 DontTouchThis
edd@rob:~$ 

This is useful when you don't want leftovers, even simple things like mypackage.Rcheck/, be owned by root which appens in Docker without a uid set.

[ProbablePattern]

I agree that would be perfect if I didn't need RStudio server.

[ProbablePattern]

I tried @eitsupi suggestion of just mounting elsewhere. This seems to work after running a script under the new username to create symbolic links in the home directory. That allows the userconf.sh script to run fast enough that everything is ready by the time the symbolic links are created in the home directory. This way everything is accessible from the file window on RStudio Server.

[eitsupi]

I would like to do away with the username change mechanism.
A warning message is now displayed when a user name is changed (#490).

If you change the user name, it is recommended that you build a Dockerfile like the following instead of doing it in the init process of rocker/rstudio.

FROM rocker/rstudio:4.2.0
ENV DEFAULT_USER=new_user
RUN usermod -l "$DEFAULT_USER" rstudio \
    && groupmod -n "$DEFAULT_USER" rstudio \
    && usermod -d /home/"$DEFAULT_USER" -m "$DEFAULT_USER"

[eddelbuettel]

I think we used that feature in the derived container we use with RStudio along with the PrarieLearn test / grade mechanism (where the backend user gets created in an underlying container, and this comes second). I presume we could live with a warning (which presumably nobody sees in backend mode...)

[cboettig]

agree with deprecating this. Changing UID makes sense (for volume mapping / permissions) but I don't think there's much purpose in renaming the user. Of course users can create additional users with whatever names they desire, which is often handy in education/training contexts.