Groups beyond 32
When changing the kernel to handle groups beyond 32, and of course the glibc as well, I noticed that I could no longer SSH out of the box.
The problem with this is not huge, ask a few questions, some more recompiling and then ssh will start working. Fine.
The problem now is more one of maintenance. Most distributions do not support groups > 32 AFAIK. So, it's lead me to ask the following questions:
1. Why, in general, is the limit so low?
For specific application, mainly auditing and such, this would be advantageous I think.
2. What is required to limit the dependence on groups to just GLIBC or just the kernel? Is that even possible?
3. Is there any true advantage to supporting more than 32 groups, or creating "meta-groups" to get around the problem?
The main reason I ask, is because just like the unknown with ssh not supporting > 32 groups without modification, there can be others. Plus with most distros, using automated upgrades via push, or some such mechanism is encumbered by customizations to glibc, ssh, and potentially other packages.
Signature · 1 line
Austin Gonyou <[email protected]>
Followup to: <1026936556.25347.48.camel@UberGeek> By author: Austin Gonyou <[email protected]> In newsgroup: linux.dev.kernel
Quoted 9 lines
The problem now is more one of maintenance. Most distributions do not support groups > 32 AFAIK. So, it's lead me to ask the following questions:
1. Why, in general, is the limit so low?
For specific application, mainly auditing and such, this would be advantageous I think.
Mostly to cap the amount of storage to maintain in kernel space, and for historical reasons.
Quoted 2 lines
2. What is required to limit the dependence on groups to just GLIBC or just the kernel? Is that even possible?
The main problem is programs who do things like:
gid_t mygroups[NGROUPS];
Other than that, it should all be in kernel space. According to POSIX, the NGROUPS above really should be sysconf(_SC_NGROUPS_MAX) -- NGROUPS_MAX is defined as a *guaranteed minimum* of sysconf(_SC_NGROUPS_MAX). Obviously there needs to be a kernel -> libc interface for the sysconf.
FWIW, POSIX specifies:
Application writers should note that {NGROUPS_MAX} is not necessarily a constant on all implementations.
(glibc has #define NGROUPS NGROUPS_MAX).
Quoted 2 lines
3. Is there any true advantage to supporting more than 32 groups, or creating "meta-groups" to get around the problem?
There probably is.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 6 lines
(glibc has #define NGROUPS
NGROUPS_MAX).Quoted 2 lines
3. Is there any true advantage to supporting more than 32 groups, or creating "meta-groups" to get around the problem?
There probably is.
We have patches to fix all this groups stuff, and I have every intention of submitting them Real Soon Now. Our offices are moving, so stuff is hither and thither.
Tim
Ahh....good to know. Thanks for all the information guys. We'll hold off till this is done I think, then come back around and see what it buys us. THX much.
Quoted 17 lines · Tim Hockin
Quoted 6 lines
(glibc has #define NGROUPS
NGROUPS_MAX).Quoted 2 lines
3. Is there any true advantage to supporting more than 32 groups, or creating "meta-groups" to get around the problem?
There probably is.
We have patches to fix all this groups stuff, and I have every intention of submitting them Real Soon Now. Our offices are moving, so stuff is hither and thither.
Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 1 line
Austin Gonyou <[email protected]>