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.
--
Austin Gonyou <[email protected]>
Followup to: <1026936556.25347.48.camel@UberGeek>
By author: Austin Gonyou <[email protected]>
In newsgroup: linux.dev.kernel
>
> 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.
> 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).
> 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
--
<[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]>
> (glibc has #define NGROUPS NGROUPS_MAX).
>
> > 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.
On Wed, 2002-07-17 at 18:42, Tim Hockin wrote:
> > (glibc has #define NGROUPS NGROUPS_MAX).
> >
> > > 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/
--
Austin Gonyou <[email protected]>
--------- Received message begins Here ---------
>
> Followup to: <1026936556.25347.48.camel@UberGeek>
> By author: Austin Gonyou <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > 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.
a. NFS v2 allows a maximum of 16 groups
b. NFS v3 allows 32.
Other distributed file systems have limits of one or the other.
> > 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.
The application is "supposed" to ask for the number of groups before
getting the array - something like the following:
size_t len = 0;
gid_t *list = NULL;
len = getgroups(0, list);
list = (gid_t *)calloc(sizeof(gid_t),len);
len = getgroups(len,list);
This still doesn't address the problem with network filesystems where
access control depends on the list of groups being passed to the server.
> (glibc has #define NGROUPS NGROUPS_MAX).
>
> > 3. Is there any true advantage to supporting more than 32 groups, or
> > creating "meta-groups" to get around the problem?
>
> There probably is.
Not to my knowlege - there ARE several disadvantages:
1. kernel table size would most likely have to be dynamic instead of static
2. searching the table is n/2 operation. The larger the table, the longer
the time spent searching.
3. distributed file system limitations.
4. Groups were not designed for general purpose access control. They were
supposed to support "project" level access. Most HR research had/has
shown that a person can't really keep track of more than about 5 projects
(tasks?) at a time. More than that tends to cause accidents in group
ownership of files (and hence information leaks from one project to
another).
ACLs would work much better for access control. "meta-groups" are normally
called "compartments", and are part of a mandatory access control. And,
unfortunately, not yet supported by distributed file system RFC specifications
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.