adds the conda path as a secure path to sudo.
The regular expression expects that the equals sign has no leading and trailing
spaces after the parameter secure_path. Furthermore it expects that the value
is enclosed in double quotes.
This is the case for the sudoers file in debian based distributions, but the
in centos / redhat based distributions this is not the case. The default value
of the secure_path in centos / redhat based distributions has no double quotes
and leading and trailing spaces.
This change adds optional spaces before and after the space, and makes the
double quotes optional.
whoami &> /dev/null || STATUS=$? && true
causes STATUS to be set to an empty string
when the container starts with option --add-group="root"
resulting in both nayvoj and jovyan having uid=1000
and gid=100. The first match in /etc/password wins
and so the container user ends up being "nayvoj"
accidentally.
Avoid this by checking that whoami STATUS is neither blank nor 0
before adding a new /etc/passwd entry
- The start.sh script does different operations on users, and
sometimes one may need to do operations *after* that is done (as
opposed to /usr/local/bin/start-notebook.d/ which is run before).
This provides that possibility. (One use case is hooks which must
be run after the users are set up.)
- To be technically perfect, one might want to use something similar
to /usr/local/bin/pre-start-notebook.d/. But let's start with the
simplest thing possible for now - the expected use of this command
is only if people use NB_USER, etc in a way that requires small
follow up commands to be run.
- If notebook is running as root, this allows users to run arbitrary
commands pre-sudo. Consider security model.
- If NB_GID is set, it is likely that files created should have NB_GID
as their gid (if it doesn't matter, then this change is irrelevant.
If it does matter, the liklihood that 100 matches with what the user
wants is low).
- When NB_GID is set, create a new group with that gid. Then, set
this as the primary gid of the user. Set the user's supplemental
gids to NB_GID,100.
Only the top level permissions are set wrong due to kubernetes not being able to do this automatically.
This hits significant problems when the chown takes more than 30s and the pod fails to start
I ran into an issue when trying to get this to work with a NFS server which I did not have direct control over (EFS). As part of the PersistentVolumeClaim, there is no easy way to set the UID and GID of the created directory.on the networked FS.
My only concern with this chown is that some user out there might be running jupyterhub in an odd configuration where $NB_USER is not supposed to have these exact permissions on the storage. I think this is quite unlikely, but it is worth mentioning.
I chronicled my experiences with working around this issue and setting up z2jh on EFS in https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/421 with @yuvipanda.
* Refactor to use sudo to become jovyna when the
container starts as root
* Retain all environment variables when becoming
jovyan
* Handle start.sh without additional commands when
launching a container as NB_USER too
Please refer to alias, in bottom of commit.
> dbn
Execute the command: jupyter notebook
> dbn bash
jovyan@eedcc93a837d:~$
> dbn start.sh
Execute the command:
exit
> dbnr
Set username to: jovyan
usermod: no changes
Set jovyan GID to: 100
Execute the command: jupyter notebook
Running as root is not recommended. Use --allow-root to bypass.
exit
> dbnr bash
root@893cb78b8c9c:~#
> dbnr start.sh
Set username to: jovyan
usermod: no changes
Set jovyan GID to: 100
Execute the command:
No arguments supplied
HOSTNAME=d45c52e788b7
TERM=xterm
SHELL=/bin/bash
NB_USER=jovyan
LC_ALL=en_US.UTF-8
PATH=/opt/conda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
_=/usr/bin/env
MINICONDA_VERSION=4.3.30
PWD=/home/jovyan
LANG=en_US.UTF-8
HOME=/home/jovyan
SHLVL=2
LANGUAGE=en_US.UTF-8
no_proxy=*.local, 169.254/16
DEBIAN_FRONTEND=noninteractive
CONDA_DIR=/opt/conda
NB_GID=100
NB_UID=1000
root@d45c52e788b7:~#
> dbnrs
Set username to: jovyan
usermod: no changes
Set jovyan GID to: 100
Granting jovyan sudo access
Execute the command: jupyter notebook
Copy/paste this URL into your browser when you connect for the first time, ....
> dbnrs bash
root@f293dce949db:~#
> dbnrs start.sh
Set username to: jovyan
usermod: no changes
Set jovyan GID to: 100
Granting jovyan sudo access
Execute the command:
No arguments supplied
HOSTNAME=d0cd57ea32e2
SHELL=/bin/bash
TERM=xterm
LC_ALL=en_US.UTF-8
USER=jovyan
SUDO_USER=root
SUDO_UID=0
USERNAME=jovyan
MAIL=/var/mail/jovyan
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
PWD=/home/jovyan
LANG=en_US.UTF-8
SHLVL=1
SUDO_COMMAND=/bin/bash -c env; PATH=$PATH; bash
HOME=/home/jovyan
LANGUAGE=en_US.UTF-8
LOGNAME=jovyan
SUDO_GID=0
_=/usr/bin/env
jovyan@d0cd57ea32e2:~$
> dbns
Container must be run as root to grant sudo permissions
Execute the command: jupyter notebook
Copy/paste this URL in..
> dbns bash
jovyan@ce5c2491fa32:~$
> dbns start.sh
Container must be run as root to grant sudo permissions
Execute the command:
exit
###### Build user setup
docker build -t $USER/base-notebook -f Dockerfile .
# Normal, dbn: docker-base-notebook
alias dbn='docker run -ti --rm -p 8888:8888 -v "$PWD":/home/jovyan/work --name base-notebook $USER/base-notebook'
# Root, dbnr: dbn with root
alias dbnr='docker run -ti --rm -p 8888:8888 --user root -v "$PWD":/home/jovyan/work --name base-notebook $USER/base-notebook'
# Jovyan SUDO, dbnr: dbn with SUDO for jovyan
alias dbnrs='docker run -ti --rm -p 8888:8888 --user root -e GRANT_SUDO=yes -v "$PWD":/home/jovyan/work --name base-notebook $USER/base-notebook'
# Root, fail to sudo for jovyan.
alias dbns='docker run -ti --rm -p 8888:8888 -e GRANT_SUDO=yes -v "$PWD":/home/jovyan/work --name base-notebook $USER/base-notebook'
- any files the user should be able to write should have group `user-permissions` with `g+rwX`
- remove `chown` from start.sh because it is no longer needed
- add `fix-permissions` script for setting the user-writable permissions on a path
- user-permissions group as GID 10000 (is there a reason for it to have a different value?)
- containers can set group with `--group-add user-writable` if they want to run with a different uid/gid
(without -u root -e NB_UID -e NB_GID, which make this unnecessary)
