[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240913161201.GB10433@brightrain.aerifal.cx>
Date: Fri, 13 Sep 2024 12:12:01 -0400
From: Rich Felker <dalias@...c.org>
To: Kate Deplaix <kit-ty-kate@...look.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: [PATCH] Increase NGROUPS_MAX from 32 to 1024
On Fri, Sep 13, 2024 at 04:00:52PM +0000, Kate Deplaix wrote:
> 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.
Can you clarify how the whole system is breaking as a result of the
macro value?
> 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.
What was established so far is that applications are using NGROUPS_MAX
as an array dimension for an automatic-storage array, which will
immediately blow up with stack overflow if we increased the value to
the kernel value. I'm aware that you proposed just using an arbitrary
lower value like 1024, which might work in practice, but I suspect
there are actually only like 3 or 4 programs that are having any
problem, and they could just be fixed to fallback to allocated storage
if a small constant-size buffer doesn't work. This is normally the way
we work through this kind of problem -- getting to the root cause and
eliminating the technical debt behind it rather than making new
technical debt to work around it.
But in order to evaluate whether this is a good option, and what the
impact of different options would be, we actually need to know what
these programs are.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
