Jovyan is not really weird, but this seems like a bug to me.
jovyan@jupyter-foo:$ groups
root users
jovyan@jupyter-foo:$ id -a
uid=1000(jovyan) gid=0(root) groups=0(root),100(users)
Why is jovyan’s group ID “root”? It should be 100, not 0.
Can someone verify they see the same? I ran this from a terminal.
Could you please provide some context? I assume it’s not a user on your local system, but from some Docker image(s). But which one(s)?
The user is already in group 100, as your output shows. Are you concerned because the primary group is root rather than users, or because you think jovyan should not be in group root at all?
Jovyan is often a special term used to describe members of the Jupyter community (https://jupyter.readthedocs.io/en/latest/community/content-community.html#what-is-a-jovyan).
tl;dr: it’s a play on “jovian” which means “a Jupiter-like planet” 
Yes I knew where the name came from. That was not my question. It was about the user Jovyan’s Linux group membership.
“gid=0(root)” seems to be incorrect.
This came about while trying to enable sudo for jovyan. I changed tact and was successful by creating a file in /etc/sudoers.d/ for the user (and not the sudo group which gave me problems).
Anyway, thanks for the response. I am unblocked.
Strangeness… Why would I get different answers below? According to the manpage, if the user is omitted, it defaults to the current user.
jovyan@jupyter-foo:~$ id
uid=1000(jovyan) gid=0(root) groups=0(root),100(users)
jovyan@jupyter-foo:~$ id jovyan
uid=1000(jovyan) gid=100(users) groups=100(users),27(sudo)
I suspect the output of id is from the current environment, while id <username> looks in configuration files for settings that would be applied to a new environment for that user.
Maybe there’s a login script that switches the primary group. Or there’s a USER jovyan:root in a Dockerfile, which fixes user and group regardless of the configuration files. You have not given any context, so we have to keep guessing instead of looking into the relevant Dockerfile.
I was seeing this using the docker image below from a terminal. What else would you like for a context?
singleuser:
image:
name: jupyterhub/k8s-singleuser-sample
tag: '0.9-b51ffeb'
Currently, I am also building my image using docker-stacks:
commit 6c3390a9292e8475d18026eb60f8d712b5b901db (origin/master, origin/HEAD, psdev-296/fix, master)
Merge: 1e37452 310afbf
Author: Min RK <benjaminrk@gmail.com>
Date: Thu Jul 4 15:58:00 2019 +0200
As far as it looking in a configuration file for a new user, that would be nonstandard. At least it is not what “man id” says nor what happens on a vanilla bionic system.
Print user and group information for the specified USER, or
(when USER omitted) for the current user.
Have you run these from your own jupyter container? It would be interesting to see what your results are.
Going to https://jupyter.org/try and using “try jupyterhub” gives this. The two id commands give different results there to.
jovyan@jupyter-jupyterlab-2djupyterlab-2ddemo-2doxluuao3:~$ id
uid=1000(jovyan) gid=1000(jovyan) groups=1000(jovyan),100(users)
jovyan@jupyter-jupyterlab-2djupyterlab-2ddemo-2doxluuao3:~$ id jovyan
uid=1000(jovyan) gid=1000(jovyan) groups=1000(jovyan)
jovyan@jupyter-jupyterlab-2djupyterlab-2ddemo-2doxluuao3:~$ groups
jovyan users
Still would like to see what you see on your containers.
Thanks, that’s the kind of context I was hoping for. You hadn’t mentioned Jupyter Hub before.
There are some layers of stacked images involved. Here’s where the user is created, without assigning a primary group:
The last statement in that Dockerfile is USER $NB_UID. And the Dockerfile reference for USER says that if one switches to a user without a primary group assigned, the group root is used.
And here’s the part where the primary group is added, shortly after the container starts up:
The “user and group information for the specified USER” comes from configuration files such as /etc/group. That script modifies /etc/group, but the process executing the script won’t be affected. At least not to the point that its primary group changes while it’s running. So when you call id jovyan, you get the updated information from /etc/groups, but id shows the actual information of the running process.
The containers I work with are built from scratch, and the user I create there does have a primary group assigned in the Dockerfile. The results wouldn’t compare to yours.
Very helpful. Thanks!. I am new to JH, but learning.
Have you enabled the RunAsGroup feature gate and set run_as_gid?
run_as_gid – The GID used to run single-user pods. The default is to run as the primary group of the user specified in the Dockerfile, if this is set to None. Setting this parameter requires that feature-gate RunAsGroup be enabled, otherwise the effective GID of the pod will be 0 (root). In addition, not setting
run_as_gidonce feature-gate RunAsGroup is enabled will also result in an effective GID of 0 (root).
The history of why the jovyan user in the jupyter/docker-stacks images is in the gid=0(root) group starts in jupyter/docker-stacks issue #188 from 2016. Various follow-on issues and PRs with additional conversation about the configuration are linked from there.