Bug 76531 - /etc/group breaks when lines longer than 671 characters
/etc/group breaks when lines longer than 671 characters
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
:
: 77156 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-22 17:05 EDT by Patrick Paul
Modified: 2016-11-24 10:04 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-09 11:42:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrick Paul 2002-10-22 17:05:36 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

Description of problem:
We have a group with 86 users.  If we put in /etc/group an entry that is longer
than 671 characters, that group is determined invalid.  chgrp doesn't work, ls
-l entries show only the uid(if the id is manually set).  Our existing 7.3 boxes
work fine with the entry

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


How reproducible:
Always

Steps to Reproduce:
1.Create /etc/group entry that has 671 characters on the line.  chgrp works fine.
2.Add one more character to make it 672.
3.chgrp breaks, saying invalid group name
	

Additional info:

Box does nightly up2date -u -f, so latest errata are always on the machine.
Comment 1 Bill Nottingham 2002-10-23 11:08:22 EDT
This is a glibc bug, AFAIR.
Comment 2 Jakub Jelinek 2002-11-06 12:06:07 EST
Can you try more recent glibc, such as glibc-2.3.1-5 from rawhide?
Cannot reproduce it with glibc-2.3.1-2, even with 737 bytes long line in /etc/group.
Also, are you using nscd or not?
Comment 3 Patrick Paul 2002-11-06 14:10:01 EST
I've started using the rpms from (I forget his name, but it's
people.redhat.com/username, or something like that).  It's glibc-2.3.1-2, and it
eliminated the group problem, and also a mysql bug that was problematic on
another system.
Comment 4 Trond H. Amundsen 2002-11-11 10:34:54 EST
Wanted to let you know that I have the problem also when using NIS, i.e.
'compat' or the like in /etc/nsswitch.conf. I'm not using nscd. The suggested
rawhide rpms fixes the problem, even lines longer than 900 characters work fine.

Another update to the problem: Any group entries _after_ a line longer than 671
don't work as well. It isn't just the long entries themselves that break, all
successive group entries will have the same problem.

(I hope this will be fixed soon, as we have 367 group entries in NIS longer than
671 characters.)
Comment 5 Alan Cox 2002-12-15 20:58:20 EST
*** Bug 77156 has been marked as a duplicate of this bug. ***
Comment 6 Trond H. Amundsen 2003-01-09 12:35:30 EST
After reducing the line lengths in /etc/group to less than 671
characters, I've come to the conclusion that this problem isn't as
easy as first reported.

The filegroup handling in glibc-2.2.93-5 is seriously crippled. It
breaks when confronted with large group entries and/or groups with
many members. I've been unable to discover any hard limits of the two
conditions that seem to be causing trouble: 1) number of characters in
the entry, and 2) number of members.

Example:

  1. Create a group 'test1234' with a 3-digit GID (in my test-case,
     the GID was 400) and 77 members, where each member's username is
     8 characters long. This works fine, even though the line is 708
     characters long. Add one more member, and it breaks.

  2. Replace the 77 8-character members with 112 members whose
     usernames are 4 characters long. This line is 575 characters
     long, and it doesn't work anymore. Remove one member, and it will
     work fine.

  3. Repeat step 2, but put in 3-character usernames. Now, we're 
     allowed to have 125 members, and the line is 519 characters
     long. Add one more member, and it breaks.

There seems to be a connection between the number of characters in the
group line and the number of members.

As stated before, it's not only the "offending" group entries that
don't work. Any entries after one such entry have the same problem.
Remove the troublemaker, and the rest won't have problems.

We have several thousands groups, and we've reduced the problem
somewhat by dividing the groups into separate entries with the same
GID but with a different name, a method we've used for years to
overcome similar limitations in other operating systems as well as
NIS. We'll probably have to reduce the line length to less than 640 to
get rid of the problem entirely, and then it's starting to get
painful...
Comment 7 Panu Matilainen 2003-01-10 07:13:22 EST
A somewhat related issue: when you have multiple groups with same GID in NIS
then on RHL8.0 no group name is shown for those groups with 'id', just the GID.
Earlier versions do show the name of the (first?) group in such cases. Upgrading
to rawhide glibc (version 2.3.1-32 tested) fixes it.
Comment 8 Aleksey Nogin 2003-02-25 14:55:21 EST
Is bug 4289 a dup of this one?
Comment 9 David Juran 2003-04-09 11:38:26 EDT
The problem I had, with NIS groups being to long, went away with the latest
glibc errata. Are the rest of the issues solved as well?

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