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 attachment 84179 [details, diff] 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 attachment 88913 [details, diff] 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?
