Re: Changing NGROUPS_MAX to 1024?

On 4/11/2026 11:57 AM, Taylor R Campbell wrote:
> Yes, we should raise NGROUPS_MAX by a lot.
>
> I drafted a patch a few years ago with the goals:
>
> 1. to keep a logarithmic bound on time to test group membership,
> 2. to avoid incurring costs on processes that aren't in many groups,
> 3. to share copies of large group arrays rather than waste kmem, and
> 4. to preserve the _first_ 16 groups as distinguished for nfs or other
>     compatibility,
>
> so it uses a reference-counted array of group ids, with those after
> the first 16 sorted for binary search lookup, of up to 65536 groups
> per credential.  It might also be worthwhile to intern large arrays
> themselves so equivalent setgroups() calls share the existing memory.
>
> But I didn't get around to finishing it.
>
> I'm not attached to this way of doing things -- I'm just sharing prior
> work and design considerations in case they're helpful.

Generally, your approach is superior, thank you.  A couple questions, 
however:

In your patch you are leaving "struct uucred" with 16 groups, which 
means that puffs would also only see 16 groups.  I don't know a lot 
about puffs.  Is 16 groups a protocol requirement the way it is with 
NFS, or does the difference not matter, or would we prefer to make more 
groups available to puffs?

I'm also not sure about goal #4.  From a kernel perspective it's easy to 
see which gids are the first 16, since they are given to the kernel in 
order; but from a user perspective it's less clear.  Group membership is 
assigned at login from groupmembership(3).  Does getgroupmembership(3) 
provide any guarantees about the ordering of the group entries it 
returns?  Or are we relying on the order specified in 
/etc/nsswitch.conf, with only the ordering in /etc/group under our 
direct control, and only meaningful if it appears first?  I don't 
believe that NIS or LDAP, for example, offer any guarantees about the 
ordering of returned groups.  Might it not be more predictable simply to 
supply the *lowest* 16 groups to NFS and other compatibility consumers?

Thanks,

--
Konrad Schroder
[email protected]