Add a group for conda commands

[raydouglass]

In order for downstream images to install conda packages as a non-root user, we should install the conda environment & packages writable by a group. So this image will now create a conda group and ensure permissions are set for group access.

Downstream images can reuse this conda group.

Required for rapidsai/docker#539

I tested locally like so:

docker buildx build -f Dockerfile -t rapidsai/mambaforge-cuda-777:cuda11.8.0-base-ubuntu22.04-py3.10 --build-arg CUDA_VER=11.8.0 --build-arg LINUX_VER=ubuntu22.04 --build-arg PYTHON_VER=3.10 .

Then build this Dockerfile:

FROM rapidsai/mambaforge-cuda-777:cuda11.8.0-base-ubuntu22.04-py3.10

RUN useradd -rm -d /home/rapids -s /bin/bash -g conda -u 1001 rapids

USER rapids

RUN mamba install -n base -y curl

[bdice]

I'd like to see a solution that doesn't modify everything to be executable (+x). It also doesn't feel like we're using privileges correctly. We should be able to resolve this by changing users before installing mamba, or some other way?

[bdice]

This is much closer to what I was hoping for! Let's rename the PR title to match the implementation, and I have one question about whether we should re-order some commands. Otherwise this could be merged in its current state.

[bdice]

Should we execute the apt-get and other "root" commands first, before copying in conda as the non-root user? Does the image need to end up in "root" mode? It would save us from switching users twice.

[ajschmidt8]

in an attempt to keep the changes to the base images to a minimum, I think we should experiment with the suggestions linked below.

• https://docs.anaconda.com/anaconda/install/multi-user/#multi-user-anaconda-installation-on-linux

they suggest utilizing linux groups to provide write access to a global conda installation.

so we could set up the group in this base image, but create the user in the downstream end-user images.

If this works, I think this should be the approach we adopt

[raydouglass]

they suggest utilizing linux groups to provide write access to a global conda installation.

The latest commit now uses a conda group and some chmod/umask commands to control the write/setgid permissions. This appears to work for downstream images.

[ajschmidt8]

Changeset

diff --git a/Dockerfile b/Dockerfile
index fccc8ff..7b31691 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,6 +1,6 @@
 ARG CUDA_VER=11.4.0
 ARG LINUX_VER=ubuntu20.04
-FROM nvidia/cuda:${CUDA_VER}-base-${LINUX_VER}
+FROM nvidia/cuda:${CUDA_VER}-base-${LINUX_VER} as base
 
 ARG LINUX_VER
 ARG PYTHON_VER=3.9
@@ -61,3 +61,11 @@ RUN case "${LINUX_VER}" in \
       echo "Unsupported LINUX_VER: ${LINUX_VER}" && exit 1; \
       ;; \
   esac
+
+FROM base as enduser
+
+RUN useradd -m -g conda rapids;
+
+USER rapids
+
+RUN mamba install -y django; conda remove -y --force-remove cffi

I tested this PR locally by running docker build . with the changeset above and confirmed that the non-root user had access to add and remove packages from the base environment.