On Tue, Mar 10, 2026 at 06:29:13PM +1100, Adam Bolte wrote: > Package: util-linux-extra > 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. [..] > 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:~$ [..] > 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.)
IMO the "sg" part of this is a distraction: The man page for shadow's newgrp [1] documents that it adds the new gid to the groupset. This is behaviour that is not present in util-linux's newgrp. It seems there is a definition question what newgrp should do. Maybe util-linux's newgrp should also add the gid to the groupset, to mirror shadow's newgrp behaviour? For Debian I was inclined to remove the sg symlink (again), but that seems pointless when the same difference exists in newgrp in the first place. Chris https://manpages.debian.org/bullseye/login/newgrp.1.en.html
