This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 3809 - usermod : group file corrupts if large number of users added to a single group
usermod : group file corrupts if large number of users added to a single group
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: shadow-utils (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
:
: 3810 7542 11930 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-29 13:15 EDT by Lee Cashmore
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-18 14:09:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lee Cashmore 1999-06-29 13:15:20 EDT
after using newusers    to add 3000 users to our system I
then required them to be put into 2 groups one called staff
one called users.

I generated a list of the usernames to be added to the staff
and users groups and did something like

for i in `cat userlist`
do
    echo "Processing user $i"
    usermod -Gstaff,users $i
done


This should have added all the users in the list to the
groups staff and users.

what II actually got is shown below
(sort of, I'm unable to put the full details in here
(........ indicates other userid's on the line)
(Sample from /etc/group)

users::100:a1000,a1001,a1002........a1678,a1679,a168
0,a1681,a1682,a1683,a1684,a1685...........a2361,a2362,a
2,a999
,a998
,a997
,a996
,a995
,a994
,a993
,a992
,a991
,a990
,a989
,a988
...........   and so on for a few hundred lines


This obviously breaks the group file. We wish to use linux
as a NIS server but if each time we add a user it's going to
break the group file we will have to look to an alternate
platform as we can't afford for the NIS group file to
corrupt each time we add a user.

I would guess this is a problem for anyone else who requires
large groups so that we can do authentication for groups in
samba. This bug was reported for redhat 5.2 as well but I
ended up having to write custom scripts of my own that
didn't break the group file. It seems as though the passwd
and user utilites have some sort of limit (string ?) but
when I put all the members of the group onto a single line
the system worked fine.

Lee
Comment 1 Jay Turner 1999-06-29 15:26:59 EDT
Changing component to shadow-utils as that is where usermod is
located.  Also forwarding to developer for further action.
Comment 2 Jay Turner 1999-06-29 15:27:59 EDT
*** Bug 3810 has been marked as a duplicate of this bug. ***

after using newusers    to add 3000 users to our system I
then required them to be put into 2 groups one called staff
one called users.

I generated a list of the usernames to be added to the staff
and users groups and did something like

for i in `cat userlist`
do
    echo "Processing user $i"
    usermod -Gstaff,users $i
done


This should have added all the users in the list to the
groups staff and users.

what II actually got is shown below
(sort of, I'm unable to put the full details in here
(........ indicates other userid's on the line)
(Sample from /etc/group)

users::100:a1000,a1001,a1002........a1678,a1679,a168
0,a1681,a1682,a1683,a1684,a1685...........a2361,a2362,a
2,a999
,a998
,a997
,a996
,a995
,a994
,a993
,a992
,a991
,a990
,a989
,a988
...........   and so on for a few hundred lines


This obviously breaks the group file. We wish to use linux
as a NIS server but if each time we add a user it's going to
break the group file we will have to look to an alternate
platform as we can't afford for the NIS group file to
corrupt each time we add a user.

I would guess this is a problem for anyone else who requires
large groups so that we can do authentication for groups in
samba. This bug was reported for redhat 5.2 as well but I
ended up having to write custom scripts of my own that
didn't break the group file. It seems as though the passwd
and user utilites have some sort of limit (string ?) but
when I put all the members of the group onto a single line
the system worked fine.

Lee
Comment 3 Dale Lovelace 1999-12-03 10:20:59 EST
*** Bug 7542 has been marked as a duplicate of this bug. ***
Comment 4 Cristian Gafton 2000-05-22 11:52:59 EDT
assign to laroche
Comment 5 Bernhard Rosenkraenzer 2000-07-18 14:09:05 EDT
*** Bug 11930 has been marked as a duplicate of this bug. ***
Comment 6 Bernhard Rosenkraenzer 2000-07-18 14:13:27 EDT
This is fixed in 19990827-16 (current rawhide).
Sorry for the long delay; the bug got assigned to the wrong people for whatever
reason.
Comment 7 jack 2001-02-12 21:51:55 EST
This is not fixed in 1990827, nor in 20000826. The solution used by the designer
was to grow the buffer as needed if the last character inputted by fgets
is not a newline. Cool enough. But the patch (hugegroups.patch in the source
rpm)
assumed that fgets does not put any '\0' at the end when the input buffer limit
is
reached, which is not the case. The fgets is retried, jumping 8192 bytes in the
input buffer.
This jumps over the '\0' left by fgets, so information is lost.
The fix is available at
ftp:/ftp.solucorpqc.ca/pub/misc/shadow-20000826-hugegroups.patch2.

This patch works on top of the hugegroups.patch.

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