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/