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...
Attachment:
pgpT0I8BFDycb.pgp
Description: PGP signature