tech-kern archive

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

Re: Changing NGROUPS_MAX to 1024?



> Date: Sun, 12 Apr 2026 13:46:30 -0700
> From: Konrad Schroder <perseant%hhhh.org@localhost>
> 
> 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 left `struct uucred' intact in order to avoid breaking any binary
compatibility.

For puffs, we may want to change the protocol so that it can pass
dynamically sized credentials or something, rather than pass around
dozens of kilobytes of data in each operation when users aren't using
it.

I hadn't thought that far ahead -- like I said, the patch wasn't
finished!

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

I hadn't thought about how userland manages the group lists.  But the
kernel approach I took gives userland the _opportunity_, at least, to
decide which groups are distinguished for NFS, even if it might take
more work for userland to take advantage of that.

Some random thoughts, barely even half-baked:

- login.conf could say which groups are distinguished
- format of /etc/group could be modified in some clever way to tag
  groups as distinguished
- nsswitch.conf could say something about group order
- new file /etc/nfsgroups could say which groups are distinguished
- if not specifically configured with distinguished groups,
  getgroupmembership could sort by gid like you suggested


Home | Main Index | Thread Index | Old Index