GRANT_SUDO on started servers

[gsemet]

Hello
I don't seem to be able to grant SUDO permission on the started instance. The container should have the GRANT_SUDO environment variable and be started as root, and the later condition does not seem to be met.

I have put this env in extraEnv and does see in the started container:

  extraEnv:
    GRANT_SUDO: "yes"

[gsemet]

so, it does not work because jupyterhub starts the user server using the user id and not root (see base-notebook/start.sh#L57.

My current mitigation is to overload the docker image with my own docker layer:

RUN echo "$NB_USER ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/notebook

[yuvipanda]

Thanks for bringing this up! We should document how to do this!

You can grant sudo by:

singleuser:
   extraEnv:
      GRANT_SUDO: "yes"
   uid: 0

The uid:0 will start the notebook as root, and you won't need extra entries.

[gsemet]

ok, and after it will still start the notebook server as joyvan as usual, right?

[yuvipanda]

It should, yeah - at least with the default image / docker-stacks images. The user id switching is done in the scripts in the image.

…

On Thu, Mar 15, 2018 at 12:51 PM, Gaetan Semet ***@***.***> wrote: ok, and after it will start the notebook server as joyvan as usual, right? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#562 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB23hg2-SqV7-Yu-5Ep75tZ9OUT06khks5tesYxgaJpZM4ScF3K> .

-- Yuvi Panda T http://yuvi.in/blog

[gsemet]

I get an error "Running as root is not recommended" when using uid: 0 and of course the extraEnv.GRANT_SUDO: "yes", like if "start-notebook.sh" isn't called, but it is, since it is the entrypoint of the image (using the base-notebook image)

[yuvipanda]

ah I forgot about that, @gsemet! Would be awesome if you can open a docs PR :)

[gsemet]

I don't have a proper solution yet, for the moment I hardcode the sudoers hack in a customized derived notebook docker image....

[consideRatio]

@manics got an idea for something to make us actionable in general about this issue?

[manics]

@consideRatio Sorry, been away for a few days. Looks like it should just work:

• sudoers is updated https://github.com/jupyter/docker-stacks/blob/137a295ff71bcdaf36047e06ba724ab842f866ef/base-notebook/start.sh#L93
• $cmd is executed as $NB_USER https://github.com/jupyter/docker-stacks/blob/137a295ff71bcdaf36047e06ba724ab842f866ef/base-notebook/start.sh#L105

[bskaggs]

@manics, @gsemet: I was able to get this working with:

singleuser:
   extraEnv:
      GRANT_SUDO: "yes"
   uid: 0
   cmd: null

By default, the chart's values.yaml hard-codes running jupyter-singleuser, rather than running /usr/local/bin/start-notebook.sh, which is the default container command for the jupyter/docker-stacks images that ultimately calls start.sh to do all the sudo magic. Setting singleuser.cmd to null restores the default behavior.

[dkipping]

@manics, @gsemet: I was able to get this working with:

singleuser:
   extraEnv:
      GRANT_SUDO: "yes"
   uid: 0
   cmd: null

By default, the chart's values.yaml hard-codes running jupyter-singleuser, rather than running /usr/local/bin/start-notebook.sh, which is the default container command for the jupyter/docker-stacks images that ultimately calls start.sh to do all the sudo magic. Setting singleuser.cmd to null restores the default behavior.

Sadly this is not an option when wanting to use jupyterlab, as one normally should set jupyter-labhub as spawner.cmd which interferes with setting the cmd: null on singleuser.

Is there currently a different option than to set the NOPASSWD:ALL manually in the custom image as proposed by @gsemet when wanting to use both jupyterlab and sudo?

NEW UPDATE:
setting JUPYTER_ENABLE_LAB as an environment variable in the container image helps :
#562 (comment)

Seems a bit hacky to me altogether, but it works.

[manics]

@dkipping Does setting JUPYTER_ENABLE_LAB work?: https://github.com/jupyter/docker-stacks/blob/87210526f381543ed76c2fba2857b1483e46bc12/base-notebook/start-notebook.sh#L10

[consideRatio]

@manics Just a quick detail plug without reading the discussion up to this point. The JUPYTER_ENABLE_LAB env. variable is utilized by the docker-stacks images' start-notebook.sh script, but to get the jupyter server aware of the JupyterHub that spawned it, we have used start-singleuser.sh instead, why I have not looked into fully yet. That script is also utilizing the JUPYTER_ENABLE_LAB env variable though, and starting jupyter-labhub binary indirectly through jupyter labhub.

[dkipping]

Yes that works. Thanks guys!

Maybe it would make the configuration work a bit more fluent, if instead of specifying jupyter-labhub as singleuser.cmd and singleuser.defaulturl in the config.yaml (or maybe adding to it), one would have a jupyterlab toggle, that when set to true will set the values in the jupyterhub configuration and set the environment variable.

On the other hand, that would make it less consistent with other usecases of defaulturl and the cmd, but jupyterlab also feels like a special case to me judging from its soon-to-be-default status.
(When setting it as default, usability of granting sudo should probably also be tested during the process.)

[jtlz2]

singleuser.uid=0 seems to throw "Running as root is not recommended. Use --allow-root to bypass." for me which prevents the container from coming up properly.

My use case is:

1. Install editor, packages etc. to container via apt-get
2. Easily run a start-up script from the command line without having to go the image registry route
3. Do the above in jupyterlab

I still can't get sudo working for jovyan despite the comments above in this thread. @dkipping Am I missing something obvious? All the envs are set for singleuser, and none for hub - right?

I can get jupyterlab working nicely but again without sudo.

Very grateful for any and all help - many thanks

[manics]

@jtlz2 can you paste or link to your configuration and Dockerfile? There are several suggestions in this thread, so please give us more detail on your current setup.

[jtlz2]

@manics Many thanks. Here you go:

helm upgrade --tiller-namespace=myns --install saturn jupyterhub/jupyterhub --namespace=myns --version=0.8.2 --values=config.yaml

config.yaml -

hub:
  # output of first execution of 'openssl rand -hex 32'
  cookieSecret: "secret1"
#  imagePullPolicy: Always
#  image:
#    name: jupyterhub/k8s-hub
#    tag: 0.8.2
  extraConfig:
    jupyterlab: |
      c.Spawner.cmd = ['jupyter-labhub']
      c.InteractiveShellApp.exec_lines = ['!pip install --upgrade pip']
proxy:
  # output of second execution of 'openssl rand -hex 32'
  secretToken: "secret2"
  service:
    type: ClusterIP
prePuller:
  continuous:
    enabled: false
  hook:
    enabled: false
cull:
  enabled: false
  # timeout:
  # every:
auth:
  admin:
    users:
      - jtlz2
  whitelist:
    users:
      - jtlz2
singleuser:
  defaultUrl: "/lab"
  #extraEnv:
  #  GRANT_SUDO:
  #    "yes"
  #uid: 0
  #cmd: null
  storage:
    extraVolumes:
    - name: secrets
      secret:
        secretName: secrets
    extraVolumeMounts:
      - name: secrets
        mountPath: "/secrets"
        readOnly: true
#  imagePullPolicy: Always
#  image:
#    name: jupyterhub/k8s-singleuser-sample
#    tag: 0.8.2
ingress:
  enabled: false

Thanks!

[manics]

  extraConfig:
    jupyterlab: |
      c.Spawner.cmd = ['jupyter-labhub']
      c.InteractiveShellApp.exec_lines = ['!pip install --upgrade pip']

This sets the startup command to jupyter-labhub. Can you try removing that and setting singleuser.cmd: null as in #562 (comment)?

[erinfry6]

I also cannot get this approach to work. I'm not trying to default to JupyterLab, so I just inserted the singleuser code. Do I need to do something else? My config file is as follows:

proxy:
  secretToken: "..."
  networkPolicy:
    enabled: true
  service:
    type: NodePort
  https:
    enabled: false

auth:
  whitelist:
    users:
      - efry
  admin:
    users:
      - admin

hub:
  image:
    name: ...
    tag: "0.8.2-0.2"

  extraConfig:
    myConfig.py: |
      c.JupyterHub.authenticator_class = 'firstuseauthenticator.FirstUseAuthenticator'

singleuser:
  storage:
    capacity: 1Gi
    extraVolumes:
      - name: mypvc
        persistentVolumeClaim:
          claimName: nfs-shared-pvc
    extraVolumeMounts:
      - name: mypvc
        mountPath: /home/jovyan/shared
  extraEnv:
    GRANT_SUDO: "yes"
  uid: 0
  cmd: null

  image:
    name: ...
    tag: 0.8

ingress:
  enabled: true
  hosts:
    - ...
  pathSuffix: '*'
  annotations:
    kubernetes.io/ingress.global-static-ip-name: jupyterhub-static-ip

[jtlz2]

@manics Extremely belatedly - just tested - your scheme works! Thank you so so much :)

JUPYTER_ENABLE_LAB not needed

[consideRatio]

Note, starting jupyter-labhub was meant to add a menu item about JupyterHub to JupyterLab. This is now done automatically with JupyterLab itself, and jupyter-labhub isn't needed any more and has been deprecated (see: https://github.com/jupyterhub/jupyterlab-hub).

Also, the JUPYTER_ENABLE_LAB interpreted by the docker-stack's start scripts are used to run jupyter-labhub. So, now we don't need that. See: https://github.com/jupyter/docker-stacks/blob/137a295ff71bcdaf36047e06ba724ab842f866ef/base-notebook/start-singleuser.sh#L37-L41

I understand it as we need to start jupyterhub-singleuser in order to let the notebook server itself be Hub aware though, and to start within jupyterlab, we need to have a defaultUrl set.

My best current understanding, on how to get JupyterLab running by default, with SUDO access for users, in z2jh, is like this:

singleuser:
  defaultUrl: /lab
  extraEnv:
    GRANT_SUDO: "yes"
    NOTEBOOK_ARGS: "--allow-root"
  uid: 0
  cmd: start-singleuser.sh

Note that GRANT_SUDO will be ignored by the start scripts unless it is started as the root user (uid=0).

UPDATE

I'm working to resolve this for myself currently, the configuration above isn't enough I think.

[ilhaan]

Based on comments above and this comment, the following config enabled JupyterLab with sudo access for users using the 0.9.0-beta.3 chart:

singleuser:
  extraEnv: 
    GRANT_SUDO: "yes"
    NOTEBOOK_ARGS: "--allow-root"
  uid: 0
  cmd: start-singleuser.sh
  defaultUrl: "/lab"
hub:
  extraConfig:
    jupyterlab: |
      c.Spawner.default_url = "/lab"

[consideRatio]

@ilhaan these parts are doing the same thing, only one is needed.

singleuser:
  defaultUrl: "/lab"

hub:
  extraConfig:
    jupyterlab: |
      c.Spawner.default_url = "/lab"

[ilhaan]

@consideRatio Thanks! I think I had that left over from an older config and didn't remove it since things were in working condition.

[manics]

I'm closing this as it seems to be resolved.

[cocampbe]

I would love to see this re-opened. This GRANT_SUDO variable is goofy. If you set the pod to run as root, what is the point of granting sudo? I want the pod to run as the jovyan user, but give the user the ability to run sudo. At this point it makes more sense to add a sudoers file in the docker file. That's the simplest and likley best option. That way I can actually put the list of commands I want to be able to have the jovyan user run.

[consideRatio]

The GRANT_SUDO variable only has meaning based on specific docker images and I want to decouple this repo's (jupyterhub helm chart repo) issues from jupyter/docker-stacks issues.

To my knowledge, this is what would be required for the GRANT_SUDO of a jupyter/docker-stacks based image to have purpose. The purpose is to start the container as root, and then transition to a specific user that is granted sudo rights by the root user just before transitioning to the specific user. It is not possible to grant sudo rights without starting the container as root initially.

The example below is relying on start-singleuser.sh - a script out of control of this repo, and GRANT_SUDO, an environment variable with meaning by this script, and NOTEBOOK_ARGS as well. Due to this, I find that the only thing in scope of this project could be to have a configuration example like below.

singleuser:
  extraEnv: 
    GRANT_SUDO: "yes"
    NOTEBOOK_ARGS: "--allow-root"
  uid: 0
  cmd: start-singleuser.sh

@cocampbe for any issue, I'd like there to be a concrete action point to the code base in the github repository. What kind of change do you suggest we include? This repo contains the documentation on how to use the JupyterHub Helm chart, and it could be in scope to document something for example. If we do document something like above, it is strictly for use with against jupyter/docker-stacks based images though.

Related in jupyter/docker-stacks

• start-singleuser.sh -> calls start.sh jupyterhub-singleuser <optional args>
• start.sh -> considers env vars like GRANT_SUDO and then starts the desired startup command

[cocampbe]

The GRANT_SUDO variable only has meaning based on specific docker images and I want to decouple this repo's (jupyterhub helm chart repo) issues from jupyter/docker-stacks issues.

This makes sense. I wasn't thinking of them as separate. I think the issue for me is that the projects are related and trying to figure out how to reconcile the two can be difficult. After reading your reply, I am in agreement. For my case, I am going to have to add a sudoer file to the docker image.