Dear Maintainer,
Sometimes I wish to gain group privileges without making the group my primary
user group. A common use case is Docker; I don't want to make my user group
permanently a member of the docker group due to security concerns, but I do
wish to run the occasional docker command without having to use sudo every
time, and without impacting the default group ownership of any files that I
create in the meantime.
For about a decade, the solution I've used has been this:
$ sg somegroup "newgrp "$(id -gn)""
ie. I have somegroup password protected with `gpasswd somegroup` and re-enter
that password whenever I wish to elevate my privileges in the manner described.
I recently happened to use Debian 13 for something (I normally use Debian 12 or
Arch), and noticed that after running the above, Docker was still giving me
"permission denied" errors. The above command was no longer adding me to the
Docker group.
Long story short, the sg command (which is a symlink to newgrp) no longer adds
the user to the supplementary group list. This appears to be a regression from
the time the sg command was switched from shadow
(https://github.com/shadow-maint/shadow) to util-linux.
To illustrate the differences in some test virtual machines:
abolte@debian12:~$ getent group docker
docker:x:109:
abolte@debian12:~$ id
uid=1000(abolte) gid=1000(abolte) groups=1000(abolte),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),106(netdev)
abolte@debian12:~$ sg docker
Password:
abolte@debian12:~$ id
uid=1000(abolte) gid=109(docker) groups=109(docker),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),106(netdev),1000(abolte)
abolte@debian12:~$ grep 109 /proc/self/status
Gid: 109 109 109 109
Groups: 24 25 27 29 30 44 46 100 106 109 1000
abolte@debian12:~$ dpkg -S "$(which sg)"
login: /usr/bin/sg
abolte@debian12:~$ apt-cache show login | grep ^Homepage
Homepage: https://github.com/shadow-maint/shadow
abolte@debian12:~$
vs
abolte@debian13:~$ getent group docker
docker:x:103:
abolte@debian13:~$ id
uid=1000(abolte) gid=1000(abolte) groups=1000(abolte),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),101(netdev)
abolte@debian13:~$ sg docker
Password:
abolte@debian13:~$ id
uid=1000(abolte) gid=103(docker) groups=103(docker),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),101(netdev),1000(abolte)
abolte@debian13:~$ grep 103 /proc/self/status
Gid: 103 103 103 103
abolte@debian13:~$ grep ^Groups /proc/self/status # No 103
Groups: 24 25 27 29 30 44 46 100 101 1000
abolte@debian13:~$ dpkg -S "$(which sg)"
login: /usr/bin/sg
abolte@debian13:~$ apt-cache show login | grep ^Homepage
Homepage: https://github.com/util-linux/util-linux
abolte@debian13:~$
(The sg symlink has since moved into the util-linux-extra package.)
My first reaction was to report this upstream, which I did so here:
https://github.com/util-linux/util-linux/issues/4098
However, the response I received was that this is a downstream bug, and that I
need to report this to Debian. I guess sg was not expected to be a symlink to
the util-linux version of newgrp yet. (Note that it was a symlink in Debian 12
to the shadow version of newgrp.)
This makes some sense. There is no sg man page (as there is from shadow on
Debian 12), and the upstream Documentation/TODO does also mention:
This is written under the login-utils / consolidate newgrp(1) bullet point,
which may imply that the expected sg functionality does not currently exist,
and should not be used the way Debian has chosen to.
Unfortunately, I am not aware of a work-around to this problem (short of
installing a custom-built binary to do the job, which I prefer to avoid for
something security-related).
Cheers.