ideas for optimizations with large groups

[David Le Corfec]

(This applies to 2.2.3, haven't checked HEAD yet)

On a large system, group member lists can be very large, and
getgrent() is slow and resource consuming, whatever the nss backend
(disclaimer: using nss_ldap here)

In lib/util_getent.c, there's a getgrent_list() function, which
is a wrapper around getgrent(). This function is only used in
rpc_server/srv_samr_nt.c:get_group_alias_entries(), which doesn't
make use of the gr_mem datas. So there should be a
getgrent_nomembers_list(), producing a list without copying
group members, and used by get_group_alias_entries().
(to be very unportable and hackish but much more optimized, I'm planning
to override nss_ldap:getgrent by requesting directly the backend with
a more specialized/efficient query)

Still in lib/util_getent.c, get_users_in_group() uses getgrent()
because "We have to enumerate the /etc/group file as some UNIX
getgrnam() calls won't do that for us (notably Tru64 UNIX)".
So a compile-time check could compile either the getgrent()
or the getgrnam() versions, choosing the most appropriate.

Bye,

-- 
David