tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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
perseant%hhhh.org@localhost



Home | Main Index | Thread Index | Old Index