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
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
Created attachment 155540 [details] improved patch, which covers same problem in useradd(#151484)
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.
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.
Good that it is in F7, but we need this backported to RHEL-4. Re-opening. Chris Lalancette
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.
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?
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
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.