This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 145492 - gpasswd -a silently violates NGROUPS_MAX limit
gpasswd -a silently violates NGROUPS_MAX limit
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-18 17:16 EST by Kenneth Porter
Modified: 2008-02-14 18:22 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-14 18:22:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kenneth Porter 2005-01-18 17:16:11 EST
I added myself to one more group in /etc/group raising my total to 33
entries and found I could no longer log in via ssh. /var/log/secure
reported "fatal: getgroups: Invalid argument". I removed the excess
entry and tried again with "gpassword -a" and found that it silently
lets me add the entry. This should issue a warning that Bad Things may
happen. usermod and any other utility that touches the group file
should issue a warning as well.

I understand from some googling about this issue that a similar thing
happens when Samba users using winbind are members of too many Windows
groups. I'm not sure why this limit exists, but it appears to be a
kernel build-time constraint.
Comment 1 Matthew Miller 2005-04-26 11:55:11 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 2 Peter Vrabec 2005-09-06 07:24:54 EDT
Actual NGROUPS_MAX limit is:
# cat /proc/sys/kernel/ngroups_max
65536
# grep NGROUPS_MAX /usr/include/linux/limits.h
#define NGROUPS_MAX    65536    /* supplemental group IDs are available */
Comment 3 Kenneth Porter 2005-09-06 18:15:18 EDT
I'd guess this got fixed somewhere between FC2 and FC4. Apparently whatever was
checking the group limit (pam_limits.so?) was looking at the constant in
/usr/include/linux/limits.h instead of the kernel's runtime value. The  higher
limit is present in FC2's kernel, but the older limit of 32 is in FC2's header
file. FC4 has 64k in the header file.

So I'm guessing this might be a PAM bug within FC2. The bug may still be present
but masked by the changed header file.
http://mail.freestandards.org/pipermail/lsb-spec/2004-March/002609.html suggests
that applications should be using sysconf(3) instead.
Comment 4 Christian Iseli 2007-01-22 05:44:17 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 5 petrosyan 2008-02-14 18:22:46 EST
Fedora Core 4 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.

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