Bug 76531

This is a glibc bug, AFAIR.

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?

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.

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.)

*** Bug 77156 has been marked as a duplicate of this bug. ***

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...

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.

Is bug 4289 a dup of this one?

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?