Bug 240915

Summary: [RHEL4] userdel/usermod infinite loop with duplicate names in /etc/group or /etc/gshadow
Product: Red Hat Enterprise Linux 4 Reporter: Chris Lalancette <clalance>
Component: shadow-utilsAssignee: Peter Vrabec <pvrabec>
Status: CLOSED ERRATA QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: mmalik, sgrubb, tao
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2007-0832 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-15 16:08:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 241585, 444107, 655088    
Attachments:
Description Flags
Patch to deal with multiple groups gracefully
none
improved patch, which covers same problem in useradd(#151484)
none
update grpconv to update_entry function none

Description Chris Lalancette 2007-05-22 20:43:31 UTC 
Description of problem:
If you have a group file that looks something like the following:

badgroup:x:30266:root
badgroup::30266:root,deleteme
deleteme:x:20750:

And you try to "userdel deleteme", userdel will go into an endless loop, leaking
memory, and can eventually crash the machine with OOM kills.  The obvious
problem here is having duplicate groups; however, it would be nicer to be more
resilient in the case of these sort of errors.

In userdel.c (and usermod.c), there is a loop that goes through all of the
groups, looking to delete the current user (in this case "deleteme") from all of
the groups.  As it goes throug each group, it removes the entry (if it exists)
from the group, then "updates" the group list with the new group.

1)  It hits the line with "badgroup::30266:root,deleteme"
2)  It removes the "deleteme", so the line would look like "badgroup::30266:root"
3)  But, gr_update() actually does a "find by name", that finds the first entry.
 It then "updates" that first entry, but doesn't fix the line it was originally
supposed to fix (the second line).
4) Now it goes to the next iteration of the loop and sees that the second line
still has deleteme, so it goes back to step 2); it does this endlessly.

Two solutions come to mind:
1)  Just bomb out when we see duplicate entries in /etc/group and/or
/etc/gshadow; that way the administrator can take corrective action without
userdel/usermod running off into the weeds.
2)  Deal with multiple group definitions gracefully.

Chris Lalancette
Comment 1 Chris Lalancette 2007-05-22 20:47:06 UTC 
Created attachment 155199 [details]
Patch to deal with multiple groups gracefully

This patch take approach 2), in that it attempts to deal with the multiple
groups gracefully.  While looking at what gr_update (and hence commonio_update)
does, it does a "find_by_name" to find the entry to update.  This is where the
problem stems from.  If, instead, we use the pointer of the current entry we
are looking for, we will always update exactly the right entry.  That's what
this patch does, by adding a new "commonio_update_entry" and the associated gr_
and gshadow_ equivalents.

Note that this is also a problem in RHEL-5 and upstream; however, I wanted to
get some feedback about whether this is the correct approach before I send it
there.	(Coincidentally, where is the upstream for this sort of stuff; I tried
shadow.pld.org.pl as listed in the SPEC, but it didn't seem to be active?)

Chris Lalancette
Comment 3 Peter Vrabec 2007-05-28 11:48:53 UTC 
Created attachment 155540 [details]
improved patch, which covers same problem in useradd(#151484)
Comment 4 RHEL Program Management 2007-06-05 20:26:53 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Since this
bugzilla is in a component that is not approved for the current
release, it has been closed with resolution deferred.  You may
reopen this bugzilla for consideration in the next release.
Comment 8 Fedora Update System 2007-06-25 23:23:41 UTC 
shadow-utils-4.0.18.1-15.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Chris Lalancette 2007-06-26 02:28:32 UTC 
Good that it is in F7, but we need this backported to RHEL-4.  Re-opening.

Chris Lalancette
Comment 13 RHEL Program Management 2007-06-29 17:54:46 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 17 Steve Grubb 2007-07-31 21:30:08 UTC 
Reviewing the improved patch. In lib/commonio.c is this:

+       tmp->eptr = db->ops->dup(newgr);
+       if (tmp->eptr == NULL)
+               return 1;

Should that return 0 since its an error?
Comment 24 errata-xmlrpc 2007-11-15 16:08:25 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0832.html
Comment 25 Kenneth Topp 2008-04-25 01:49:00 UTC 
Created attachment 303718 [details]
update grpconv to update_entry function

all commands that call gr_next after running gr_update on a dup group are at
risk.

at least grpconv is.  patch attached.


groupadd - only update a non existant group, however broken nsswitch could make
getgrnam return 0, and find_by_name would get a dup. but luckily the gr_next
occurs before gr_update
newusers -similar to groupadd
grpunconv - needs to be fixed, can fix just like my attached patch, if it's
desirable.