The problem is that NGROUPS_MAX is used in downstream projects, not sysconf(_SC_NGROUPS_MAX). Notoriously one of the main user of musl (Alpine Linux) does not modify this value which makes the whole system break completely if a user happens to be added to more than 32 groups. Changing every opensource projects that use NGROUPS_MAX to use sysconf(_SC_NGROUPS_MAX) instead doesn't seem like a reasonable answer to me, even if it might be the correct one in theory. I also really don't understand why you want to support 20+ years old kernel versions (pre 2.6.4) which aren't even POSIX conformant according to your own page: https://wiki.musl-libc.org/supported-platforms. I also don't think it would also break anything on those platforms anyway if a higher value was used. Most uses i've seen use this value to allocate a static array, so aside from a couple more bytes of memory used there isn't much to lose. Cheers, Kate ________________________________ From: Rich Felker Sent: 13 September 2024 15:47 To: Kate Deplaix Cc: musl@lists.openwall.com Subject: Re: [musl] [PATCH] Increase NGROUPS_MAX from 32 to 1024 On Fri, Sep 13, 2024 at 11:45:13AM +0000, Kate Deplaix wrote: > Hi, > > Is there anything i can do to make a fix for this go forward? What requirements are you still trying to satisfy? 3f49203c55cc made it so initgroups accepts arbitrarily many groups independent of NGROUPS_MAX. My reading of POSIX is that the macro NGROUPS_MAX is a "minimum maximum" that any instance of the implementation might impose, which for us I think is the 32 imposed by old Linux. sysconf(_SC_NGROUPS_MAX) does not yet expose a larger runtime max; is that what you'd like to see happen? Source I'm going on: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/limits.h.html under the heading "Runtime Increasable Values". Rich