This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 148994 - usermod gshadow corruption
usermod gshadow corruption
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-17 15:11 EST by Bill Gradwohl
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-25 10:52:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Bill Gradwohl 2005-02-17 15:11:32 EST
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 06:11:42 EST
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 08:19:49 EST
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 08:22:51 EST
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 10:52:06 EST
thx. to Mogens Kjaer for that patch.

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