Date: Mon, 23 Mar 2009 12:23:47 -0400 From: Boris Kochergin <spawk@acm.poly.edu> To: n0g0013 <ttw+bsd@cobbled.net>, freebsd-hackers@freebsd.org Subject: Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h? Message-ID: <49C7B793.1090308@acm.poly.edu> In-Reply-To: <20090323155433.GA24517@holyman.cobbled.net> References: <49C6F4F4.5030609@acm.poly.edu> <20090323124502.GA8686@holyman.cobbled.net> <49C79A9B.9070309@acm.poly.edu> <20090323155433.GA24517@holyman.cobbled.net>
next in thread | previous in thread | raw e-mail | index | archive | help
n0g0013 wrote: > On 23.03-10:20, Boris Kochergin wrote: > [ ... ] > >> Well, bumping it does get rid of messages like: >> >> Mar 22 20:44:26 hydrogen sshd[96152]: getgrouplist: groups list too small >> Mar 22 20:44:26 hydrogen sshd[96152]: fatal: initgroups: [user]: Invalid >> argument >> > > yes, that's great but you may be surprised to learn that it doesn't > actually solve your problem. i think (and without looking > specifically at the impact my even be confident enough to say > definately) if you get a groups list it will only be cropped and the > error message is being erroneously avoided, not corrected. i'd also > suggest that you may be opening up your system to some overflows > although, generally, the code sections use the same limits and so > you might get away with it. > > [ ... ] > >> I'd love to see a resolution to this other than having to recompile the >> kernel. Let me know if I can help things along somehow. >> > > if you can grab my patch, confirm it builds for you and that it doesn't > crash your system , that would be a big help. unfortunately i was > going to test it on my xen box only to discover that it doesn't work > with amd64 yet. i'm currently coding blind and am not a good > programmer so this is bad[tm]. > > if you can do this and are happy to run a few further tests after that > then i'll be sure to put some heat under the rest of the process and > get the group limits removed correctly. > > On my 7.0 system, and a kernel recompiled with NGROUPS_MAX set to 64, a getgrouplist() call for a user who is in more than 16 groups (24, to be exact) will populate the array specified by the "gid_t *groups" argument with the 24 groups the user is in, in addition to the group specified in the "gid_t basegid" argument. The value of the variable specified in the "int *ngroups" will also be 25, and the getgrouplist() call will return 0. So, as far as being a hack for a specific problem, it seems to work properly. Sure, I'll test the patch. Can you point me at it? -Boris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49C7B793.1090308>