Re: ngroups

[christos%astron.com@localhost (Christos Zoulas)]

In article <rmi1tolfrqb.fsf%fnord.ir.bbn.com@localhost>,
Greg Troxel  <gdt%ir.bbn.com@localhost> wrote:
>-=-=-=-=-=-
>
>
>Jukka Marin <jmarin%embedtronics.fi@localhost> writes:
>
>> On Fri, Nov 28, 2014 at 04:33:22PM +0000, Michael van Elst wrote:
>>> You can try to change NGROUPS_MAX in sys/featuretest.h and rebuild
>>> the system. It's a compile time constant in many places (not just
>>> the kernel) which is also used for stack objects. So enlarging
>>> it a bit might work, making it substantially larger probably causes
>>> problems.
>>
>> Hmm. :(  We need to control users' access to files and directories
>> and 16 groups may not be enough.  (At least it leaves no room for
>> future changes.)  Do you know what the biggest problem with a large
>> ngroups would be?  Can't be memory consumption these days, I think..
>
>It should be easy enough to change it to 32 or 64 and do a full build.
>Note that you may break ABI compatibility, but I'm not clear on that.
>Then, you can put the resulting system through a full atf run, either on
>hardware or via anita.
>
>I think mlelstv meant by "making it substantially larger probably causes
>problems" that values like 1024 or 8192 are not going to work.  32 seems
>pretty likely to work, or easy to fix.  Every factor of 2 larger is a
>bit scarier...

If you are going to bother with that, perhaps create pools of group sets,
or do what linux does.

christos