On Tue, Apr 22, 2003 at 06:28:26PM +0100, Phil Mayers wrote:
No no no no. getgrall could theoretically return a *huge* number of groups, and/or individual groups could have *huge* numbers of members. For a system with /etc/passwd and /etc/group only, this doesn't matter, but think about a system with an LDAP (RFC2307) nameservice backend - I just tested it on my machine, and getgrall results in over 48Mb of LDAP queries based on our ActiveDirectory groups. Many tens of seconds.
However, calling initgroups results in a single query:
memberUid=foo
...and only returns the groupname and gid, so is efficient every time.
Certainly you are correct. The point you are missing is that we are programming in Python, not in C. And Python does not have initgroups. We could add initgroups into eunuchs (http://twistedmatrix.com/users/tv/eunuchs/), or use the initgroups module by one of the Twisted developers; the code could be rewritten to try importing the C part, and falling back to the dumb version. Then using the smart API would be a true optimization. However, before I touched it, the code did _NOTHING_ unless the C initgroups module was available. And that resulted in bad things.
The "right" way to do this is the getgrouplist() call (see http://www.openbsd.org/cgi-bin/man.cgi?query=getgrouplist) and if you look at the NSS code in e.g. glibc the NSS modules can provide "efficient" hooks which initgroups() and getgrouplist() can implement. initgroups() in glibc basically calls getgrouplist() on the NSS plugin and so whilst the *result* is the same, you're taking the slow path.
getgrouplist() is as much missing from python stdlib as initgroups(), so you aren't really helping there. -- :(){ :|:&};: