Jupyter should run as the project's group

[tdudgeon]

The group ID that Jupyter runs as should be the project's group ID.
Currently it runs as:

uid=10001 gid=100(users) groups=100(users),2005,20001

This means that the group ownership of files created by Jupyter is 100 (users) rather than the project's group.

Doing some tests running in Docker it looks like this can be fixed with these options:

docker run -d -p 8888:8888 --rm --name jupyter --user root -v $PWD/jupyter_demo:/home/jovyan -e JUPYTER_ENABLE_LAB=yes -e NB_UID=5000 -e NB_GID=500 jupyter/base-notebook start-notebook.sh

The NB_UID and NB_GID would obviously be the user's ID and the project's ID.
This results in a user profile like this:

uid=5000(jovyan) gid=500(jovyan) groups=500(jovyan),100(users)

Notice that the user is still a member of group 100 so should still be able to access /opt/conda.
Files that are created in a terminal or notebooks that are created get the expected ownership:

-rw-rw-r-- 1 jovyan jovyan   0 Nov 29 16:14 tim
-rw-rw-r-- 1 jovyan jovyan 616 Nov 29 16:15 Untitled.ipynb

The docs also suggest that -e NB_UMASK=002 would be needed, but it seems that this is the default anyway.
The CHOWN_HOME and related options should not be needed as the ownership of the mounted volume should already be correct.

The one downside that I can see on this is the need for the --user root option. But this probably isn't too much of a problem. If the user opens a terminal from the Jupyter lab interface the user has already been switched to the jovyan user. Only if you ssh directly to the pod do you end up as root, and we don't allow users to do this, and even if we did they would only have access to that container and the data that was mounted into it.

See here for documentation on all these options.

[alanbchristie]

I've tried these combinations in the past and fear that the requirement to run the container as root is simply "robbing Peter to pay Paul". According to the documentation of the NB_UID and NG_GID variables: -

For this option to take effect, you must run the container with --user root

Using the Kubernetes equivalent of --user root conflicts with one of our key designs - the use of DM-assigned User and Project IDs in the Project volume for file permissions. Running a container 'as root' renders this part of our design pointless. Do we have have an "opinionated" file-system (managed by the DM), or not?

Isn't the problem here that the Jupyter application assumes that the group ID is 100? Is the "real"/"elegant" solution to deploy a Jupyer that doesn't, i.e. one that can genuinely "run as any user"? Not sure that's possible but running as root might just result in accumulating technical debt.