[email protected] wrote:
On 22.03-22:33, Boris Kochergin wrote:
Ahoy. I got bitten by this today--a system I administer for someone had
users in more than 16 groups, so I had to bump the value, recompile the
kernel, and reboot. It seems desirable to (at the very least) make this
a read-only tunable that can be set using /boot/loader.conf, so as to
avoid source modification and kernel recompilation. I had a look around,
and noticed that NGROUPS_MAX is used to construct static arrays in a
couple of locations ("ibcs2_gid_t iset[NGROUPS_MAX];"). It seems that
malloc(9)/MALLOC(9) can be used to allocate memory for the array
instead, and panic() (or something) can be called if the allocation
fails, no? Is that about the gist of it? If I'm not overlooking
something major, I'd like to take a stab at it.
i've sumbitted a patch for this to hackers@' list but actually
bumping the groups limit is more work. i'm pretty far on with it
but am unsure wwhen it'll be completed. if anyone wishes a copy of
the patches or current working patch then i'd be happy to post it.
note that bumping NGROUPS_MAX will do little in itself.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
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
...and allows users who are in more than 16 groups to log in. I think
there's something to be said for that. Anyway, thanks for the update.
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.
-Boris
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
