Bug 148994 - usermod gshadow corruption
Summary: usermod gshadow corruption
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: shadow-utils
Version: 3
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-02-17 20:11 UTC by Bill Gradwohl
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-02-25 15:52:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Replacement maxmem patch (1.63 KB, patch)
2005-02-23 13:22 UTC, Mogens Kjaer
no flags Details | Diff

Description Bill Gradwohl 2005-02-17 20:11:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
executing usermod -G corrupts /etc/gshadow. The more often its run, the more severe the corruption becomes.

Version-Release number of selected component (if applicable):
shadow-utils-4.0.3-56

How reproducible:
Always

Steps to Reproduce:
1.groupadd sambashare
2.useradd xyz
3.usermod -G sambashare xyz
At this point, gshadow is corrupt, but only by a small amount.
Add a few more users and keep executing usermod -G sambashare for each user and the corruption grows exponentially.
  

Actual Results:  after 80 users were added to the sambashare group, the gshadow file was a bit over 95Meg in size and all the commands (useradd, groupadd, usermod) would start taking longer and longer to execute as the file size grew. At the end they took 3.5 minutes to execute, and according to top were using 95% of memory (1G+2Swap).

Additional info:

Heres the top while groupadd is running, about 30 seconds into it:
top - 20:25:33 up 1 day,  3:26,  3 users,  load average: 1.19, 1.24, 1.25
Tasks:  52 total,   3 running,  49 sleeping,   0 stopped,   0 zombie
Cpu(s): 23.0% us,  9.0% sy,  0.0% ni,  0.0% id, 67.7% wa,  0.3% hi,  0.0% si
Mem:   1035980k total,  1030268k used,     5712k free,     1168k buffers
Swap:  2032212k total,   259104k used,  1773108k free,    16236k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
6181 root      18   0 1205m 959m  116 R 31.1 94.8   0:14.26 groupadd
 177 root      15   0     0    0    0 D  1.0  0.0   4:04.83 kswapd0
6175 root      15   0     0    0    0 S  0.3  0.0   0:00.03 pdflush
   1 root      16   0  3032   88   68 S  0.0  0.0   0:01.02 init
   2 root      34  19     0    0    0 S  0.0  0.0   0:02.66 ksoftirqd/0
   3 root       5 -10     0    0    0 S  0.0  0.0   0:00.13 events/0
   4 root       5 -10     0    0    0 S  0.0  0.0   0:00.01 khelper
  16 root      15 -10     0    0    0 S  0.0  0.0   0:00.00 kacpid
 113 root       5 -10     0    0    0 S  0.0  0.0   0:25.66 kblockd/0

Comment 1 Mogens Kjaer 2005-02-23 11:11:42 UTC
If you:

Rebuild the shadow-utils rpm from the SRPMS file.

rpm --nodeps shadow-utils

rpm -i /usr/src/redhat/RPMS/i386/shadow-utils-4.0.3-37.i386.rpm

then the gshadow file doesn't get corrupted.

gcc problem?

Comment 2 Mogens Kjaer 2005-02-23 13:19:49 UTC
Hm, this was complete nonsense; I had installed
shadow-utils-4.0.3-37.src.rpm instead of
shadow-utils-4.0.3-56.src.rpm.

The problem is the patch: shadow-4.0.3-maxmem.patch
included in -56.

I've attached at patched patch of this file.

Comment 3 Mogens Kjaer 2005-02-23 13:22:51 UTC
Created attachment 111333 [details]
Replacement maxmem patch

Fixes a problem where the counters nadmins and nmembers
don't get reset between each call of sgetsgent

Comment 4 Peter Vrabec 2005-02-25 15:52:06 UTC
thx. to Mogens Kjaer for that patch.


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