FS#16092 - [shadow] groupadd always add system groups with gid=99

Attached to Project: Arch Linux
Opened by Anton Leontiev (bunder) - Tuesday, 08 September 2009, 05:39 GMT
Last edited by Allan McRae (Allan) - Sunday, 28 February 2010, 04:34 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:
When I try to add system group with default /etc/login.defs it always creates group with gid=99, even if '-o' option isn't specified and group with this gid is already exist (nobody).
$ sudo groupadd --system test
$ getent group test
test:x:99:
This happens because of login.defs file provided with 'shadow' package. In this file following value are defined:
UID_MIN 1000
UID_MAX 60000
GID_MIN 100
GID_MAX 60000
While the group manipulation utils by default set SYS_GID_MIN to 101 and SYS_GID_MAX to GID_MIN-1 if GID_MIN is defined or to 999 if isn't. Thus in present configuration 'groupadd --system' searches for free gid's in range from GID_MIN=101 to GID_MAX=99!!! So it always sets gid for new group to 99. (This is of course error of shadow, because it must report an error in this case as I think.)

I see two ways to resolve this problem:
1. Change the default value of GID_MIN to 1000. This is reasonable as gids within range [100,1000] already used as system gids by many packages (policykit, for example).
2. Introduce SYS_GID_MAX, SYS_GID_MIN to provided 'login.defs' explicitly.

I think we should apply both changes.

Additional info:
* package version(s): shadow 4.1.4.2-1

Steps to reproduce:
When using default login.defs try to run 'groupadd --system newgroup' as root.
This task depends upon

This task blocks these from closing
 FS#16941 - [wireshark] 1.2.2-1 should install dumpcap suid root 
Closed by  Allan McRae (Allan)
Sunday, 28 February 2010, 04:34 GMT
Reason for closing:  Fixed
Additional comments about closing:  shadow-4.1.4.2-2
Comment by Aaron Griffin (phrakture) - Tuesday, 08 September 2009, 22:55 GMT
What changes need to be made to existing systems to accommodate this?
Comment by Anton Leontiev (bunder) - Wednesday, 09 September 2009, 15:25 GMT
To my knowledge no changes are necessary. Just added before non-system groups will now be in system groups range, but this must not affect on a functionality.
Comment by Aaron Griffin (phrakture) - Tuesday, 22 September 2009, 18:49 GMT
Thomas, opinions here?
Comment by Thomas Bächler (brain0) - Tuesday, 22 September 2009, 19:39 GMT
Hmm, increasing GID_MIN to 500 looks good I think. But I don't have a strong opinion here, I have no idea what the purpose of groupadd --system would be.
Comment by Anton Leontiev (bunder) - Saturday, 26 September 2009, 10:48 GMT
And what about if I want to write PKGBULD for some package and this package needs its own system group like hal or policykit.
Gid of 'hal' group and other common groups have the common defaults. So all gids below 100 are reserved as I understand.
How can I find free gid for the new group above the 100. Some gid are reserved by policykit and others. I've decided that using 'groupadd --system' is the most correct way. And I really don't understand why gid for policykit is hardcoded.
And about GID_MIN=500. What arguments you have for this value. I'm asking because the default value of 'shadow' itself is 1000, and why you want to set 500?
Comment by Thomas Bächler (brain0) - Saturday, 26 September 2009, 16:50 GMT
I'm not exactly sure why, I'm also fine with changing it to 1000.
Comment by ux (ubitux) - Tuesday, 06 October 2009, 19:43 GMT
This issue creates lots of surprises (example when creating svn user). If you try something like: useradd -r -U svn, you will have:

% grep 99 /etc/group
nobody::99:
svn:x:99:

It breaks lots of things: no author/date/message in commits for example. You will have packages like gitosis unusable too (which use useradd) because of this.
Comment by Anton Leontiev (bunder) - Saturday, 10 October 2009, 09:06 GMT
About the possible conflicts with the proposed configuration I want to note, that if some package will create system group with gid=102 using 'groupadd --system' before policykit (for example just after installing your system you install two packages which add their system groups using 'groupadd --system'), when after installing policykit, which has its gid=102 hardcoded, you will obtain two groups with same gid. To avoid these conflicts all packages that potentially have gid>100 should use 'groupadd --system' command to add their groups to the system.
Or we can move lower boundary to, say, 150. And then say, that packages like policykit, which are "very" system packages, have hardcoded gids in the range [101,150]. But in this case I don't understand how one can find free gid in this range to add its own "very" system package.
So I am for the first solution. What do you think about this?
Comment by Benoit Izac (benizac) - Friday, 27 November 2009, 22:23 GMT
I think there is a real problem with the uid/gid management in Archlinux.
Shadow is a little bit responsible because if you use gid 1 to 15 and have a gid 85, groupadd will never use 16 to 84 (and there is no way to do it).

For me, the good way to manage uid/gid is:
1-99: reserved accounts (hardcoded)
* only for well know services (general purpose)
* a predefined list should exist somewhere on the system so packagers can refer to it

100-999: system accounts (SYS_UID_MIN = SYS_GID_MIN = 100, SYS_UID_MAX = SYS_GID_MAX = 999 in /etc/login.defs)
* for accounts automatically created by package (ie. getent user snort || useradd -s snort)
* remove all hardcoded uid/gid from pkg.install files (grep -r 'useradd.*-u *[0-9]' /var/abs)

1000-60000: normal accounts (UID_MIN = GID_MIN = 1000, UID_MAX = GID_MAX = 60000 in /etc/login.defs)
Comment by Aaron Griffin (phrakture) - Wednesday, 02 December 2009, 17:20 GMT
Tagging Allan and Dan here, as they tend to be knowledgeable about this level of things.

There's a lot of ideas floating around here. Could someone summarize them into a patch against the files from ABS?
Comment by Allan McRae (Allan) - Saturday, 05 December 2009, 10:25 GMT
Looking at this, we really need to not reserve groups with GIDs > 100 and just use "groupadd --system" instead. So fixing this really requires fixing all packages that specifically set a GID above 100.

According to http://wiki.archlinux.org/index.php/UID_and_GID_list, we need to deal with the packages for these groups:
policykit, deluge, cherokee, vboxusers, partimag, gdm, qmail, nofiles
Comment by Benoit Izac (benizac) - Saturday, 05 December 2009, 15:13 GMT
According to
% grep -r 'useradd.*-u *[0-9][0-9][0-9]' /var/abs
% grep -r 'groupadd.*-g *[0-9][0-9][0-9]' /var/abs

in format package:user/group:uid/gid, we have:

* useradd
extra/deluge:deluge:125
extra/gdm:gdm:120
extra/policykit:102:policykit
community/dspam:dspam:115
community/partimage:partimag:110
community/postgrey:postgrey:314
community/pulseaudio:pulse:130

* groupadd
extra/deluge:deluge:125
extra/gdm:gdm:120
extra/policykit:policykit:102
community/dspam:dspam:115
community/partimage:partimag:110
community/postgrey:postgrey:314
community/vlock:vlock:129
community/pulseaudio:pulse:130
community/pulseaudio:pulse-access:131
community/pulseaudio:pulse-rt:132
community/adesklets:adesklets:107
Comment by Paul Mattal (paul) - Saturday, 06 February 2010, 23:33 GMT
I think this is an acceptable patch to achieve what we want, based on what I've read. Any objections to applying this? If so, will apply/test on March 2010 bug day.
   shadow.patch (0.4 KiB)
Comment by Benoit Izac (benizac) - Saturday, 06 February 2010, 23:57 GMT
You could also add:
SYS_UID_MIN 100
SYS_UID_MAX 999
Comment by Paul Mattal (paul) - Sunday, 07 February 2010, 00:20 GMT
Right. Also fixed my broken syntax. Anything else?
   shadow.patch (0.4 KiB)
Comment by Allan McRae (Allan) - Sunday, 07 February 2010, 01:12 GMT
This is not a bug day endeavour... It requires fixing of the packages listed above so really needs a coordinated rebuild in [testing]. I will organise that once KDE moves out.

e.g. I could "groupadd --system" a few times making group 102 and then install policykit which specifically creates group 102, resulting in "two" group 102's.
Comment by Paul Mattal (paul) - Sunday, 07 February 2010, 03:13 GMT
Got it. Rather than undo all of that, I wonder if we should just raise the SUS_UID_MIN and SYS_GID_MIN to 500. Is there a downside to doing that?

The highest hardcoded id seems to be postgrey at 314.
Comment by Allan McRae (Allan) - Sunday, 07 February 2010, 03:18 GMT
I figure that we might as well fix it properly in one go. Otherwise, once this bug is fixed, the motivation to do the rest will disappear and we will be left with the half fix for the future.
Comment by Paul Mattal (paul) - Sunday, 07 February 2010, 03:23 GMT
I only wonder about this because there are some programs (mailman, as I recall) that actually need to be compiled with the gid fixed numerically at compile time. If any of these is one of those, what do we do then?
Comment by Allan McRae (Allan) - Sunday, 07 February 2010, 03:28 GMT
Standard approach is to give them a GID<100.

Loading...