I've been working on fixing the limit of 15 groups per user. This has primarily consisted of merging a patch from Isilon Systems which breaks the group array out of struct ucred and stores in in malloc'd storage. I've attached a patch which includes that change and increases the value of NGROUPS_MAX to 32767. It also changes references to cr_groups[0] to use the cr_gid macro and introduces a new crsetgroups() function for use by random bits of code that fill in credentials (usually partial ones) Additionally, a number of arrays that used to be of length NGROUPS have been changed to use XU_NGROUPS (from xucred) or their own definition which is 16 to avoid excessive bloat. Most of these should probably be change to use dynamic allocation. In general, when something could not take more groups, I have chosen to truncate the list rather than fail. This may raise issues with negative permissions, but complete failure is likely to cause problems for more people. If it's a major issue this can be made tunable. As I mentioned above, many thing should be redone to support dynamic allocation, but all the RPC related things can not. I'd like people to test and review this patch with the aim of getting it and some of the other work I've been doing in subversion in to 8.0. You can find all of it at http://svn.freebsd.org/base/projects/ngroups. Before any merge a couple decisions need to be made: - How large should NGROUPS_MAX be? Linux uses 65536 and we could extend things to support that, but it's probably unnecessary. - Should we make any attempt to support old binaries when there are more than 16 groups? The POSIX getgroups/setgroups APIs did not anticipate this change and thus either will fail outright. We can't fix setgroups, but we might want to make an optional accommodation for getgroups to allow for truncated returns to old code. -- Brooks
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:49 UTC