misc/113398: initgroups fails rather than truncates if number of groups > NGROUPS_MAX meaning the user can no longer login

[Dean Povey]

>Number:         113398
>Category:       misc
>Synopsis:       initgroups fails rather than truncates if number of groups > NGROUPS_MAX meaning the user can no longer login
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 06 02:20:01 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     Dean Povey
>Release:        5.2 (although I believe this bug exists in the current HEAD)
>Organization:
Quest Software
>Environment:
>Description:
A few years ago a change was made to initgroups.c (revision 1.8 in CVS) to have initgroups fail rather than silently truncate the number of groups when more than NGROUPS_MAX is returned by getgrouplist.

While the reasoning behind this change is understandable back in the pre-NSS days when you could reasonably assume all groups came from /etc/groups this is not appropriate for NSS based systems which source their group information from external sources such as LDAP.  In this situation a change to the external directory to add an additional group (which does not cause an issue on systems such as Linux or Solaris that truncate), will mean that the user can no longer log in on FreeBSD.  The specific scenario which this breaks is the case where an Active Directory repository that is supplemented with Unix UID and GID information is being used via NSS.  It is extremely common for the number of groups in this scenario to exceed NGROUPS_MAX (typically 15 because of the NFS restriction).




>How-To-Repeat:
1. Create a user and add them to more than 16 groups.
2. Attempt to login, login fails.

>Fix:
I believe the correct approach is to revert the change to initgroups.c which added the error checking and allow the groups to be silently truncated.  Any applications that care whether the group list is truncated should be calling getgrouplist first to determine the number of groups anyway and then either logging this fact or failing.  This would make FreeBSD consistent with Linux and Solaris (and I believe although have not verified that HP-UX and AIX also work this way).

The only side-effect is that in cases where the group permissions on objects are more restrictive than the "others" permission this could lead to a security problem.  However, this is generally a bad idea anyway because the behavior is not secure on other platforms.  It seems better to recommend against this edge case than deny the user the ability to login.

>Release-Note:
>Audit-Trail:
>Unformatted: