Re: [musl] [PATCH] Increase NGROUPS_MAX from 32 to 1024

[Kate Deplaix <kit-ty-kate@outlook.com>]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

Hi,

Is there anything i can do to make a fix for this go forward?

Cheers,
Kate
________________________________
From: Laurent Bercot <ska-dietlibc@skarnet.org>
Sent: 11 April 2024 12:44
To: musl@lists.openwall.com <musl@lists.openwall.com>
Subject: Re: [musl] [PATCH] Increase NGROUPS_MAX from 32 to 1024

>I had a look at Debian Codesearch for NGROUPS_MAX, to see what
>applications are actually doing with the macro. And I found no instance
>of anyone using it as an array size.

  I do. e.g.
https://git.skarnet.org/cgi-bin/cgit.cgi/s6/tree/src/daemontools-extras/s6-applyuidgid.c#n22

  It's in small short-lived utilities that don't allocate anything, so
I'm
not too worried about overflowing the stack, but the change would not be
friendly to resource-constrained environments.

  My code runs on not-so-conformant systems such as Solaris or MacOS,
where
I'm not sure that sysconf() and _SC_NGROUPS_MAX are even defined and
correct.
I can test, but that's more work, and convoluted heuristics to make
things
support every case are a strong decrease in readability and reliability,
an additional portability nightmare I don't want to deal with. Whereas
NGROUPS_MAX works everywhere.

  I'm not sure what the best course of action is. I think it still
probably
is eating the ephemeral 256kB stack penalty if NGROUPS_MAX is increased
to 65536.

--
  Laurent


[-- Attachment #2: Type: text/html, Size: 2463 bytes --]