Bug 60304 - 'usermod' cannot add more than 800 users into a group.
Summary: 'usermod' cannot add more than 800 users into a group.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: shadow-utils
Version: 7.2
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-02-25 03:32 UTC by Mitsuo Hamada
Modified: 2007-04-18 16:40 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-10-27 18:12:02 UTC
Embargoed:


Attachments (Terms of Use)
My proposed patch fixing the issue. (440 bytes, patch)
2002-10-03 21:35 UTC, Leszek Matok
no flags Details | Diff

Description Mitsuo Hamada 2002-02-25 03:32:36 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)

Description of problem:
'usermod' cannot add more than 800 users into a group.

# cat account.txt
a0001
a0002
.
.
.
a0999
a1000

# addgroup hello

# for acc in `cat account.txt`
>do
>adduser $acc
>usermod -G hello $acc
>done

After executing above shell script, I found /etc/group was broken.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.make account list more than 800.
2.addgroup hello
3.execute script written bellow.
for acc in `cat account.txt`
do
adduser $acc
usermod -G hello $acc
done
	

Actual Results:  /etc/group file was broken.

Expected Results:  all users are added into 'hello' group.

Additional info:

Comment 1 Need Real Name 2002-06-18 09:53:03 UTC
Problem looks to be in a 4096 byte barrier somewhere - I found this problem 
also to exist when I add a user with adduser and secundairy groups; right at a 
4096 byte length line it's broken and the groupfile is truncated (and thus 
broken)

Comment 2 Daniel Drown 2002-06-19 17:56:33 UTC
I ran into this as well.

fix is in shadow cvs at:
http://cvs.pld.org.pl/shadow/lib/commonio.c?r1=1.19&r2=1.20

comment from the above fix:
2001-09-07  Tomasz K3oczko  <kloczek.pl>
	* lib/commonio.c, NEWS:
	Fix bug discovered and fixed by Marcel Ritter <Marcel.Ritter.de>
	Due to a big buffer size in lib/commonio.c this error does only appear
	if a line gets longer than 4096 bytes (there are probably very few people
	stumbling across this).
	Ths bug can be exposed by trashing /etc/groups file using useradd with script:
		#!/bin/sh
		typeset -i NUM
		NUM=0
		groupadd demogroup
		while [ $NUM -le 1000 ]; do
		   useradd -g demogroup -G demogroup -p "NONE" user$NUM
		   NUM=$NUM+1
		done

After applying the above patch to the source, I was able to create a group that
exceeded 4096 characters with the usermod tool.

Comment 3 Daniel Drown 2002-07-13 00:01:35 UTC
this also affects RedHat 7.3

Comment 4 Leszek Matok 2002-10-03 21:33:49 UTC
This affects newest RawHide packages, and Red Hat 8.0. I have a multiuser system
and the current number of users causes useradd to delete all my users' groups,
truncating the 'users' group. I'm attaching my own patch applying clearly to
shadow-utils-20000902-12 sources, which I came up with when trying to understand
what is happening to my system. It doesn't use any dynamically allocated
integer, contrary to PLD patch. This also isn't the perfect patch. It allocates
4096 bytes and reads at most 4095 at a time, so on a system with one /etc/group
line having 8192 characters, it wastes 2 bytes. What a pity :) Works for me now,
but I'm really disappointed on Red Hat having the patch since almost two years
(take a look at bug 3809!) and doing nothing, when the tools they provide delete
their users' and clients' data...

Comment 5 Leszek Matok 2002-10-03 21:35:21 UTC
Created attachment 78444 [details]
My proposed patch fixing the issue.

Comment 6 Leszek Matok 2002-10-03 21:48:55 UTC
Oh, by the way, building an rpm with my patch, I have noticed:
useradd.o(.text+0x5c4): the use of `mktemp' is dangerous, better use `mkstemp'
Maybe it's harmful, but also doesn't give me the sense of security a Linux
distribution should provide.

Comment 7 Leszek Matok 2002-10-03 22:08:19 UTC
I meant "harmless", please excuse me.

Comment 8 Dave Brown 2003-02-17 02:29:05 UTC
Any ideas as to when we can expect this bug fixed?

Comment 9 Per Steinar Iversen 2003-03-21 13:17:36 UTC
Just discovered this bug the hard way on RedHat 8.0, a trashed /etc/group file.
Not very nice for large linux servers. This is really bad for enterprise sized
servers. Will this be fixed in version 8.1 ?

Comment 10 Dave Brown 2003-04-29 00:22:38 UTC
This appears to be fixed in RedHat 9 however it is still broken in RedHat 7.2. 
Any ideas as to whether this will be fixed in 7.2 seeing as it goes End Of Life 
at the end of this year?


Note You need to log in before you can comment on or make changes to this bug.