[PATCH] winbind nested groups fix?

[Matthijs Kooijman]

> This code certainly looks a lot simpler and more compact than a good fix
> to getgrent would be, but I'm not clear how much of the problem it
> solves.  The problem to be solved, from my POV (please correct me if I
> am wrong) is that if I have a user U who is a member of group A which in
> turn is a member of group B, then when I type 'getent group B' I should
> see U in that entry.
Yes and no :-) While this would indeed be correct (and fix the problem on at
least FreeBSD), it appears that fixing getgrent would require a lot of testing
and finding corner cases, which is circumvented by not supported nested groups
in getgrent right now.

FreeBSD currently does the following. When a user logs in, it calls
"getgrouplist" to get the list of groups for the user. This then calls
getgrent for all (!) known groups and iterates them to see in which groups the
user is in. As you can imagine, this is really non-scalable already.

The fix for this is forwarding the "What are this user's groups?" request
directly through nss, instead of translation it into a zillion "What are this
group's members?" requests that can be forwarded.

My (unfinished) patch to FreeBSD does exactly that (by calling the
"getgroupmembership" nss function). This patch enables Samba to understand
FreeBSD "getgroupmembership" nss function. This function calls the winbind
getgroups function, which properly resolves nested groups already.

This will still not show all the members in the userlist of a group containing
groups (since getgrent is not fixed), but this will work well enough for
file system permissions.

> Also, I need a Linux solution: if a patch like this one were ported to
> the Linux libnss_winbind, would it fix the problem?
Funny you should ask. As far as I have understood so far, this should Just
Work (tm) on Linux already. NSS on Linux should do pretty much the same thing
I described above, only by calling the initgroups_dyn function instead of the
getgroupmembership function. 

As far as I can see, nested groups not working on linux would be a bug. That
is, if you do not see the members in the group, this is expected as explained
above. But running "id <username>" should report the correct groups for a
given user.

> Final comment on the patch: enumerating group members is not likely to
> be a frequent operation, but some (of my) groups may have quite a lot of
> members, so I'm a little concerned about the performance implications of
> the linear search to eliminate duplicate members, especially as the scan
> will normally fail (not a duplicate).
It's exactly the other way around. This will only enumerate the groups a user
is in. So, unless your users are in a lot of groups, this should not really be
a problem I think (since the call should only be made on user logins I think).

Gr.

Matthijs