Mounted volume permissions in rootless containers

[kmfrick]

Disclaimer: I know this is a known issue with rootless docker. I am posting this here because I think this is related to rocker-org/rocker#324 and rocker-org/rocker#295 .

Which host OS you are using

OS: Arch Linux x86_64 Kernel: 5.4.6-arch1-1

Which Docker container(s) you tried

rocker/rstudio

What command you launched

I tried these two ($UID = 1000): [0] docker run -e USERID=$UID -e DISABLE_AUTH=true -p 127.0.0.1:8787:8787 -v /home/kmfrick/Documents/Code/:/home/rstudio/code rocker/rstudio [1] docker run --user 1000 -e DISABLE_AUTH=true -p 127.0.0.1:8787:8787 -v /home/kmfrick/Documents/Code/:/home/rstudio/code rocker/rstudio Docker is running in rootless mode (started with systemctl --user start docker).

What you were expecting

A /home/rstudio/code directory that I could read from and write to inside the container.

Which error you get

[0] Everything under /home/rstudio/code is owned by root so there is no write access. [1] s6-mkdir: warning: unable to mkdir /var/run/s6: Permission denied

[cboettig]

Thanks for the bug report. Regarding [1], you can't run rstudio server as a regular user, so your run command won't work like that regardless of whether or not you are linking an external volume. You can run a different default command if you like (R, or even an rsession for RStudio), but the default command is init, which uses the S6 init system to set up user configurations and then start RStudio Server.

Regarding [0], that does sound strange. Have you been able to test that when starting your Docker engine in the default mode (i.e. without the --user flag)?

[kmfrick]

Thanks for the bug report. Regarding [1], you can't run rstudio server as a regular user, so your run command won't work like that regardless of whether or not you are linking an external volume. You can run a different default command if you like (R, or even an rsession for RStudio), but the default command is init, which uses the S6 init system to set up user configurations and then start RStudio Server.

Noted, thank you.

Regarding [0], that does sound strange. Have you been able to test that when starting your Docker engine in the default mode (i.e. without the --user flag)?

Everything works as intended when starting docker in root mode (and using sudo docker run to start rocker). I can read from and write to the /home/rstudio/code folder, stat -c "%u" code returns 1000 which is my UID in the host machine.

What I don't understand is why stat -c "%u" code returns 0 when run inside a rootless container. Does S6 mount volumes as root, even when run inside a rootless container, and then chown them? So in that case the chown would be failing inside the rootless container, for some reason. Does S6 require host system root permissions to operate inside the container? That would be a security issue, in my opinion. Thanks a lot for helping further reasoning!

[cboettig]

@kmfrick apologies for the slow reply, I've been away.

I don't think you're seeing any behavior that's specific to S6 init system or rocker in general. I haven't played around much with the --user flag, but if you run a container with root permissions (inside the container) and bind a volume to the local host, and then inside the container, the root user changes ownership of a directory that you've bound to the host, what is the expected behavior on the host system?

That's really all that you're seeing here. You can see our userconf.sh which is being run when the rstudio container starts up to help ensure that we consistently map user, uid, groupid, etc permissions between host and container. This script was developed prior to docker having a --user flag, and generally for a secure environment most users seem to prefer going with singularity, (many sys admins won't install docker anyway due to this issue with root permissions, but I'm not an expert in this area and as i've said, I'm not up to speed on --user mode for the whole docker engine).

Anyway, if you see a way we can improve userconf.sh to be compatible with running the docker daemon in this mode and still linking local volumes, I'm all for it.