My patch is very lightly tested and I didn't try to use the additional testcases. 

I get test failures, but no crashes, when I do run the additional tests. I haven't had time to review the testcases though. 

What I did notice though is that the tests don't actually test the issue at hand: having more than 16 secondairy groups on OSX.

I'm not too thrilled about your approach of growing the grouplist argument of getgroups until the results fit, the comment in the coreutils sources refers to two very old unix flavors and IMHO it is not worthwhile to try to support those.

Wrt. the value of MAX_GROUPS on Linux: we could change the test that defined MAX_GROUPS to ensure that the value doesn't get too large, from:

#ifdef NGROUPS_MAX


to:

#if defined(NGROUPS_MAX) && NGROUPS_MAX <= 64

This combined with my patch would result in less stack usage while still working when a user has a lot of secondary groups.


I agree that Apple's patch is broken, it almost certainly reads the secondary groups from the user database instead of returning the actual value for the running process (based on the prototype and additional includes).