Bug 143308 - grpck interprets the gshadow file incorrectly
grpck interprets the gshadow file incorrectly
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Depends On:
  Show dependency treegraph
Reported: 2004-12-18 11:16 EST by Jørgen Thomsen
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

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

Attachments (Terms of Use)
dynamically allocate list function (2.40 KB, patch)
2005-01-29 19:49 EST, Zing
no flags Details | Diff
fixed maxmem.patch from Mogens Kjaer (mk@crc.dk) (1.63 KB, patch)
2005-02-28 04:21 EST, Peter Vrabec
no flags Details | Diff

  None (edit)
Description Jørgen Thomsen 2004-12-18 11:16:25 EST
From Bugzilla Helper:
User-Agent: Opera/7.54 (Windows NT 5.1; U)  [en]

Description of problem:
grpck does not interpret the lines of the gshadow file correctly.
It even happens after deleting the gshadow file and recreating it 
with grpconv

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

How reproducible:

Steps to Reproduce:
1. grpck -r

Actual Results:  shadow group bin: no user oot
delete member `oot'? No
shadow group daemon: no user
delete member `'? No
shadow group daemon: no user x
delete member `x'? No
shadow group daemon: no user ot
delete member `ot'? No
shadow group daemon: no user in
delete member `in'? No

Expected Results:  nothing

Additional info:


Comment 1 Ben Thomas 2004-12-20 11:44:56 EST
I have verified this on three different servers.

Comment 2 Peter T 2004-12-23 16:14:02 EST
Confirmed with shadow-utils-4.0.3-56 too.
Comment 3 Ben Thomas 2005-01-04 16:53:47 EST
shadow-utils-4.0.3-21.i386 does not exhibit this behavior.
Comment 4 Ben Thomas 2005-01-10 11:51:07 EST
Just wanted to mention that I'm seeing this issue on Fedora Core 2. Do
I need to send in the necessary patches or is someone already working
on this issue?
Comment 5 Carlos Moio 2005-01-14 11:28:42 EST
I have the same failure on a Fedora Core 2 like Ben Thomas. How can 
be resolved? There is any way to fix it?
Comment 6 J. Nick Koston 2005-01-18 07:45:52 EST
This is a pretty serious problem as we run grpck daily to ensure
uptime in the event of /etc/group corruption.
Comment 7 Joey 2005-01-23 18:41:01 EST
Yes we are having the same issue on one of our Fedora core 2 servers. 
We hope this will be fixed soon/
Comment 8 Zing 2005-01-29 19:47:47 EST
the maxmem patch is horked.  is there any reason why the code in
sgetgrent.c can't be used?  attaching...
Comment 9 Zing 2005-01-29 19:49:12 EST
Created attachment 110404 [details]
dynamically allocate list function
Comment 10 Michael Styne 2005-01-31 12:57:53 EST
I've rebuilt the shadow-utils RPM with Zing's modified maxmem patch.
It's available at:


I've only tested it on my home machine, running FC3, and it seems to
work. (Where 'work' == 'doesn't spit out nonsensical errors') YMMV,
use at your own risk.

I hope to test it with a few FC2 boxes later today. Hopefully this can
tide us over until a fixed RPM comes Down From Above(tm).
Comment 11 Peter Vrabec 2005-02-28 04:21:10 EST
Created attachment 111466 [details]
fixed maxmem.patch from Mogens Kjaer (mk@crc.dk)
Comment 12 jack 2005-11-07 17:52:20 EST
I am having this same problem with FC3 and need to get the fix, up2date is not 
showing anything newer then:
shadow-utils                            4.0.3          56                i386

Which I re-installed to be sure.

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