posted patches to this effect some months ago. they needed some
clean-up and validation but the also mapped correctly into an
RPC_NGROUPS_MAX and IPC_NGROUPS_MAX for consistent (and possibly
dynamic) mapping to those problem areas. they build and run but are
untested beyond that. i do not expect
On 25.03-05:31, David Schultz wrote:
[ ... ]
> A person's Copyright doesn't go away just because they die,
> disappear, or fail to respond. If you can't contact them, their
> heirs, or whomever they transferred the Copyright to, you're stuck.
yeah but it's a little like finding something. if ther
On 22.03-22:33, Boris Kochergin wrote:
> Ahoy. I got bitten by this today--a system I administer for someone had
> users in more than 16 groups, so I had to bump the value, recompile the
> kernel, and reboot. It seems desirable to (at the very least) make this
> a read-only tunable that can be s
On 23.03-00:39, David Schultz wrote:
[ ... ]
> There's already a kern.ngroups sysctl, but there are many places
> where `ngroups' needs to be used in preference to NGROUPS in the
> kernel. In userland, sysconf(_SC_NGROUPS_MAX) needs to be used in
> preference to NGROUPS_MAX.
you will also note tha
On 21.02-22:49, Julian Elischer wrote:
[ ... ]
> >this patch should remove the dependancy on the definition of
> >NGROUPS_MAX as a static constant and implement it as a writable
> >sysconf variable of the same. it should also make the necessary
> >changes to the codebase to support those.
[ ... ]
attached is the first in a series of patches that is intended to
remove the current limitation on group membership.
this patch should remove the dependancy on the definition of
NGROUPS_MAX as a static constant and implement it as a writable
sysconf variable of the same. it should also make the ne
6 matches
Mail list logo
