Julius von Kohout

i am happy to donate again for this feature if it is implemented.

@DavidSpek is this still relevant?

@kubeflow/wg-notebooks-leads can we move forward with this? There is already a PR for the centraldashboard at https://github.com/kubeflow/kubeflow/pull/6072/files

is this something you want @kubeflow/wg-notebooks-leads ?

Ok,then UID 1000, GID 100 must be set in the securitycontext of the pod. Otherwise the common default is used, which is usually not 1000:100 ``` apiVersion: apps/v1 kind: Deployment...

The s6 init system is broken by design, but there might be a workaround ``` [julius@fedora 1.3]$ podman run -p 8888:8888 --user 1000:100 --entrypoint='/bin/bash' public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/jupyter-scipy:v1.3.0-rc.0 -c 'ls -lah /var/run' lrwxrwxrwx....

> `/var/run/s6` is created on container startup as far as I know, so the folder is owned by the creator. Otherwise, it would also fail to start when using docker...

This works and shows how broken s6 is security-wise. ``` apiVersion: apps/v1 kind: Deployment metadata: name: test1 namespace: kubeflow-user spec: replicas: 1 selector: matchLabels: app: test1 template: metadata: labels: app:...

So a workaround would be to add 1. securitycontext 1000:100 2. emptydir volume 3. volume mount to /var/run/s6 4. S6_READ_ONLY_ROOT env as shown above to the statefulset. ShouId i create...

> I don't think supervisord can properly handle multiple processes while running in a docker container or make it easy for people to run startup scripts, but that is beside...