I generally keep system groups under GID 1000, special purpose user groups between 1000 and 1999, and general user groups between 2000 and 2999. I also have one special purpose group at 10000. nogroup falls in at 65533 and nobody is at 65534. It's been a long time since adding a group. I should have been more diligent in noticing what Portage was doing when adding groups. In looking at the groups currently defined, I find: lpadmin:x:106: crontab:x:2000: ddclient:x:2001: ices:x:2002: link-master:x:10000: realtime:x:10001: pulse-access:x:10002: pulse:x:10003: asterisk:x:10004: fax:x:10005: With the exception of link-master, these should all be system groups below GID 1000. In looking into the enewgroup function in eutils.eclass, I see the function is letting the groupadd command use the default GID_MIN/GID_MAX in login.defs. It should be using the -r option to groupadd to allow use of SYS_GID_MIN/SYS_GID_MAX. I'll attach a diff with my fix. In looking at this code, I also had a question. The groupadd command is in a case command that checks for *-darwin*, *-freebsd*|*-dragonfly*, *-netbsd*, and * (* being Linux). The following code is repeated for each case except *: for ((egid = 101; egid <= 999; egid++)); do [[ -z $(egetent group ${egid}) ]] && break done First, do these other platforms lack support for login.defs? Second, assuming the first is true, why code the same block of code three times if the fourth option is the only exception? Thanks for looking into this and for answering my question. Chris Reproducible: Always Steps to Reproduce: 1.emerge anything that generates a group without a predefined GID 2. 3. Actual Results: Group gets assigned a GID based on GID_MIN/GID_MAX Expected Results: Group should be assigned a GID based on SYS_GID_MIN/SYS_GID_MAX emerge --info Portage 2.1.6.7 (default/linux/x86/2008.0/server, gcc-4.1.2, glibc-2.6.1-r0,glibc-2.3.4.20040808-r1, 2.6.27-gentoo-r8 i686) ================================================================= System uname: Linux-2.6.27-gentoo-r8-i686-Intel-R-_Pentium-R-_4_CPU_2.40GHz-with-glibc2.0 Timestamp of tree: Thu, 12 Mar 2009 08:00:04 +0000 distcc 3.0 i686-pc-linux-gnu [disabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -fomit-frame-pointer -fforce-addr -pipe -O2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib/fax /var/bind /var/lib/citadel /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=pentium4 -fomit-frame-pointer -fforce-addr -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://chod.cwru.edu/gentoo http://mirror.datapipe.net/gentoo http://gentoo.mirror.icd.hu/ http://gentoo.binarycompass.org" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/srv/nfs/overlay/hoganskeep /srv/nfs/overlay/layman/voip" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl alsa apache2 ares bash-completion berkdb bzip2 caps cli cracklib crypt cups dedicated doc dri encode extensions flac fortran gdbm glibc-omitfp gnutls gpm h323 hpn iconv imap ipv6 isdnlog jabber java kerberos ldap libclamav lm_sensors logrotate mailwrapper midi mmx mudflap mysql ncurses nfs nls nptl nptlonly oav offensive ogg openmp pam pcre perl pic pie pppd pulseaudio pwdb python quotas readline reflection samba sasl sendmail session slp snmp speex spell spl sse sse2 ssl subversion sysfs syslog tcpd theora threads truetype unicode userlocales vorbis webdav x86 xattr xinetd xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intelintel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_defaultauthn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias proxy proxy_http" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 185077 [details, diff] eutils.eclass enewgroup patch to use SYS_GID_MIN/MAX
A lot of people including me have this problem, and indeed, -r or --system should be used to add a system group, see man groupadd. Thanx for writing a patch Christopher! I hope this one will be fixed in portage soon since I don't like to change gids manually (including a find / -group <oldgid> -print0 | xargs -0r chgrp -hc <newgid>) for every new added system group.
Also seeing this on fresh installs. At some point in the past, this behaved correctly, because my UID/GID is 1000/1000. Now I have to change the IDs on all these extra groups Portage created. :/
Hi, Same problem here, which led me to spend too much time on this. This can cause very strange behaviour on systems using alternate auth backends, such as NIS or LDAP, and, what is more, could drive to security holes, since some regular users of the alternate backends can belong to the same "distant" groups that some running daemons (with "local" groups with the same gid) ! Maybe severity of this bug should be changed ?
As I see it, bug #264519 is a duplicate of this one, but also includes a request for enewuser. I already put 10 votes on that bug.
base-system, what is the status here?
Neither groupadd nor useradd in current eclass use -r option. This means that currently, and in the last months, users have installed systems on which some daemons are running with UIDs / GIDs which are commonly affected to users (by convention, uid > 1000 are for users, as gid > 100 are for user groups). If such a system is used with a distant authentication backend (LDAP / NIS / MySQL / PostGreSQL...), there are good chances that this backend used the convention to create user accounts with uids and gids already used in local by daemons. When such a user logs in, he can interact with these daemons easily (start / stop / restart / and far more) . This bug is not only a bug, it can be a HUGE security hole too !
It's now more than one year ago this bug report was created. Any chance this bug will be solved in 2010 ?
3 months later... Maybe someone can take a few seconds to add 17 bytes to eutils.eclass and solve this problem ?
+1 on it, but we need to make extremely sure that it's not going to generate GIDs that conflict with other static ones (really however, all system UID/GIDs should be static).
That's why I believe we've got GLEP 27, however the implementation in there is pretty miserable. I've actually committed this for now after discussing it a bit with Chainsaw. If I remember when I discussed something like this with Mike a while back he said we really should just implement GLEP 27 instead. But hey I could be wrong. If there's pieces from this, I'll pick them up.
Hi Thank you very much for solving this. It will simplify my life a lot ;-).
