Messages in this thread | | | From | Tim Hockin <> | Subject | Re: [BK PATCH 1/4] fix NGROUPS hard limit (resend) | Date | Fri, 25 Oct 2002 11:17:29 -0700 (PDT) |
| |
> example group file extract: > webroot:x:103:www,jim,joy > custadm:x:140:%webroot,bob,carol,ted,alice > webcusts:x:1000:%webcust1,%webcust2,%webcust3 > webcust1:x:1001:%custadm,%custwebs,Matt,Christoph > webcust2:x:1002:%custadm,%custwebs,Suparna,Aaron,Tim > webcust3:x:1003:%custadm,%custwebs,Randal,Jesse
I've always wanted something like this. It really is not too difficult to do, but it is entirely a library problem.
> Now, changing it at this level would require that > the libs be updated (but so would infinite groups) > and a way to inform the kernel of the nested group > memberships.
unlimited groups requires a TRIVIAL change to libc.
> For informing the kernel i lean toward a sysfs > interface fed by a user-space utility that would > build or update a pinned table. The in-kernel group > lists would be unrolled (per the example > webroot=custadm,webcust1,webcust2,webcust3)
gahh..Why does the kernel need to know about a group and members? At login time (or rather, setgroups() time, likely login, but could be other) getgrent() or whatnot does a full expansion on the nested group file (handling recursion properly!). You call setgroups() with the full list of GIDs for your user. The kernel should not know about a group beyond a GID, unless we're talking about vastly different semantics than traditional users and groups.
> There would be problems with existing utilities due
problems with things that parse /etc/group. Not problems with things that use the getgr*() functions.
> It also provides a way to have 400 (out of 16000) > users in a group without infinite line length in > /etc/group.
Line length is/was an real issue. Last I tried to do something like having 5000 users in a group, libc would not parse it. Can't say I've tried lately. That, however, is another purely library problem.
> The important thing either way would be that you would save > on memory for group lists and it would work over NFS without > a protocol change.
No, it wouldn't work on NFS except to another system which understands this scheme. The patch I proposed uses CoW grouplists. This is good enough for the vast majority of cases - not too many apps call setgroups() themselves, being a restricted syscall, and all that.
> I've actually wanted the nested group memberships for a long > time.
So have I, but it is a different problem...Patches should be sent to glibc developers.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |