tags 445485 wontfix tags 445485 upstream thanks On Sat, Oct 06, 2007 at 09:36:37AM +0200, [EMAIL PROTECTED] wrote: > > as i'm working with the group database, i can't miss a quite > simple to implement feature addition: allowing groups to be > members of groups.
It is in fact much more complicated. Other parts of the system will have to be changed first. At least come to my mind: libc, coreutils, pam. It is mostly the libc which reads the groups file (getgroups(3), getgrent(3), etc.). Then if the libc implement this, shadow can support this feature by allowing group name to be added as member of group (and a tag will be needed to differentiate groups and users: maybe @group). > currently, the only deeper change would be to make the > 'groups' underlying call list members as currently, > and list members of members, in the case they are groups. > same groups should not be delved in more than once. > > specifically, the groups programm should also allow for a > special call, showing the original (not recursed in) list > of groups that directly contain the user. > > if viable, i might try to help. I've set the bug as wontfix, and I don't expect this will be implemented ever. I will reconsider it if the feature get supported by libc. What I recommend if you really want to simplify the handling of group on your system is either to use another group database (maybe LDAP suports this), or use an intermediate layer to generate the group file. Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
