Bugzilla Bug 128715

This is whith shadow-4.0.15:
(handbook example)
# useradd -m -G users,wheel -s /bin/bash larry
# id larry
uid=1002(larry) gid=1002(larry) groups=1002(larry),10(wheel),100(users)
It creates a "larry" group instead of using "users" as the inital group.
Also it doesn't seem to honor the GROUP setting in /etc/default/useradd:
# grep GROUP /etc/default/useradd
GROUP=100
# useradd alice
# id alice
uid=1003(alice) gid=1003(alice) groups=1003(alice)

# emerge --info
Portage 2.1_pre7-r3 (default-linux/x86/2005.1, gcc-3.4.6, glibc-2.3.6-r3,
2.6.15-gentoo-r7 i686)
=================================================================
System uname: 2.6.15-gentoo-r7 i686 AMD Athlon(tm) XP 2600+
Gentoo Base System version 1.12.0_pre16
dev-lang/python:     2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild
/etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig collision-protect distlocks metadata-transfer
parallel-fetch sandbox sfperms strict"
GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/
http://ftp.easynet.nl/mirror/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 3dnow X aac alsa apache2 apm avi bash-completion berkdb bitmap-fonts
bzip2 cdr crypt curl dri dvd dvdr emboss encode ffmpeg firefox flac foomaticdb
gdbm gif gpm gtk gtk2 hal imlib isdnlog jpeg kde kdeenablefinal kdexdeltas
libg++ libwww mad mikmod mmx motif mp3 mpeg musicbrainz ncurses nls nptl
offensive ogg oggvorbis opengl oss pam pdflib perl png pppd python qt quicktime
readline ruby sdl spell sse ssl tcpd theora tiff truetype truetype-fonts
type1-fonts usb vorbis win32codecs xine xml2 xv zlib elibc_glibc
input_devices_keyboard input_devices_mouse kernel_linux userland_GNU
video_cards_ati"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, LINGUAS

(In reply to comment #0)
> This is whith shadow-4.0.15:
> (handbook example)
> # useradd -m -G users,wheel -s /bin/bash larry

-G are supplementary groups, primary group is specified with -g

> Also it doesn't seem to honor the GROUP setting in /etc/default/useradd:
> # grep GROUP /etc/default/useradd
> GROUP=100

seems true here (4.0.14-r1), suspected USERGROUPS_ENAB setting from
/etc/login.defs also doesn't have any effect on this.

Created an attachment (id=84179) [edit]
shadow-fix-useradd-usergroups.patch

this should fix the issue i think

(In reply to comment #2)
> shadow-fix-useradd-usergroups.patch
> this should fix the issue i think

This patch fixes the issue only if USERGROUPS_ENAB=no. But if it set to 'yes' I
have the same result:
theor home # useradd test
theor home # id test
uid=1007(test) gid=1007(test) groups=1007(test)

Useradd still creates group 'test' instead of use the value from
/etc/default/useradd:
GROUP=100

But may be that is the right behaviour because it's really not clear for me
what does this mean:
# Enable setting of the umask group bits to be the same as owner bits
# (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is
# the same as gid, and username is the same as the primary group name.

As I understand the previous sentense, USERGROUPS_ENAB should affect umask, but
not useradd.

> This patch fixes the issue only if USERGROUPS_ENAB=no. But if it set to 'yes'
> I have the same result:

that's the entire point ... the behavior you're seeing now is not a bug imo,
but proper behavior

if you dont want user groups, disable USERGROPUS_ENAB

i'm still waiting for feedback from upstream on the issue though

This is pretty annoying.
With which version of shadow has that behaviour been introduced?

(In reply to comment #5)
> This is pretty annoying.
> With which version of shadow has that behaviour been introduced?

We just realized this problem today.  For us, this was introduced when we
upgraded from 4.0.7-r4 to 4.0.14-r1.  In 4.0.7-r4 useradd correctly used the
default group setting in /etc/defaults/useradd.  I just upgraded to 4.0.15-r2
to see if anything has been fixed, and it is still broken.

Created an attachment (id=88913) [edit]
shadow-fix-useradd-usergroups.patch

more fixes

ok, this should be fixed in shadow-4.0.16-r1

we're still hashing out the final details upstream but at least our shadow wont
be completely screwed up in the meantime :)

I'm running shadow 4.0.17-r1 and have this same issue (pointed out to me by
user Paapaa on the forums). Is this a regression, or per comment #8 have
discussions with upstream resulted in this change being considered correct
behavior?